MSIT - A2 - Mod6 - Gestion y Desarrollo de Sistemas

Módulo
Gestión y Desarrollo
de Sistemas
Módulo
Gestión y Desarrollo
de Sistemas
1. CRITERIOS DE SELECCIÓN.................................................................................... 09
1.1. CRITERIOS RACIONALES.................................................................................. 09
1.1.1 COSTES DIRECTOS.................................................................................... 10
1.1.2 COSTES INDIRECTOS................................................................................. 10
1.1.3 OTRAS MEDICIONES DE COSTES............................................................... 11
1.1.4 CALIDAD.................................................................................................. 11
1.1.5 FACTORES DE BLOQUEO........................................................................... 12
1.2. CRITERIOS DERIVADOS DEL ENTORNO............................................................ 13
1.3. CRITERIOS INFLUENCIABLES............................................................................ 15
1.4. CONCLUSIONES.............................................................................................. 15
1.5. RESUMEN DEL TEMA....................................................................................... 15
2. VIRTUALIZACIÓN DE SERVIDORES...................................................................... 16
2.1. INTRODUCCIÓN A LA VIRTUALIZACIÓN DE SERVIDORES................................. 16
2.2. VIRTUALIZACION DE SERVIDORES................................................................... 19
2.2.1. MOVIMIENTO DE MÁQUINAS.................................................................. 20
2.2.2. ALTA DISPONIBILIDAD.............................................................................. 21
2.2.3. GESTIÓN DE RECURSOS........................................................................... 22
2.2.4 TOLERANCIA A FALLOS............................................................................. 22
2.2.5 RECUPERACIÓN DE SEDE.......................................................................... 23
2.3. GRANDES OPCIONES...................................................................................... 23
3. VIRTUALIZACIÓN Y OTRAS TECNOLOGÍAS........................................................ 28
3.1. VIRTUALIZACIÓN DEL ALMACENAMIENTO...................................................... 28
3.2. VIRTUALIZACIÓN DE LAS REDES...................................................................... 29
3.3. VIRTUALIZACIÓN DEL PUESTO DE TRABAJO.................................................... 31
3.3.1 VIRTUALIZACIÓN DE ESCRITORIO............................................................. 33
3.3.2 VIRTUALIZACIÓN DE APLICACIÓN............................................................ 33
3.3.3 VIRTUALIZACIÓN DE LA PRESENTACIÓN................................................... 34
3.3.4 VIRTUALIZACIÓN DE PERFIL...................................................................... 34
3.4. CONCLUSIONES.............................................................................................. 36
3.5. RESUMEN DEL TEMA....................................................................................... 37
4. GREEN IT............................................................................................................... 38
4.1. INTRODUCCIÓN AL CONCEPTO GREEN IT....................................................... 38
4.2. DISEÑO DE CPD EFICIENTES............................................................................ 40
4.3. ESTRATEGIAS DE EMPRESARIALES EFICIENTES................................................. 48
4.4. RESUMEN DEL TEMA....................................................................................... 50
5. CLOUD COMPUTING............................................................................................ 51
5.1. INTRODUCCIÓN AL CONCEPTO ..................................................................... 51
5.2. SAAS............................................................................................................... 53
5.3. PAAS............................................................................................................... 54
5.4. IAAS................................................................................................................ 55
5.5. XAAS.............................................................................................................. 55
5.6. CLOUD PRIVADO............................................................................................. 56
5.7. CLOUD PÚBLICO............................................................................................. 57
5.8. CLOUD HÍBRIDO.............................................................................................. 57
5.9. RESUMEN DEL TEMA....................................................................................... 59
6. INFRAESTRUCTURA TECNOLÓGICA.................................................................... 60
6.1. HISTORIA........................................................................................................ 60
6.2. MERCADO DE SERVIDORES............................................................................. 61
6.3. EL ENTORNO DE ALMACENAMIENTO.............................................................. 62
6.4. LAS COMUNICACIONES.................................................................................. 63
6.5. ESTADOS DE MADUREZ.................................................................................. 64
6.5.1. ESTADO 1: COMPARTIMENTADO Y PROPIETARIO..................................... 65
6.5.2. ESTADO 2: ESTANDARIZADO................................................................... 65
6.5.3. ESTADO 3: OPTIMIZACIÓN....................................................................... 65
6.5.4. ESTADO 4: AUTOMATIZADO Y ORIENTADO AL SERVICIO........................ 66
6.5.5. ESTADO 5: INFRAESTRUCTURA ADAPTATIVA........................................... 66
6.6. PLAN DE ACCION............................................................................................ 66
6.7. RESUMEN DEL TEMA....................................................................................... 68
7. ARQUITECTURA EMPRESARIAL........................................................................... 69
7.1. INTRODUCCIÓN AL CONCEPTO...................................................................... 69
7.2. NIVELES DE GRANULARIDAD VS. NIVELES DE ABSTRACCIÓN.......................... 72
7.3. MODELO DE UNIFICACIÓN.............................................................................. 73
7.4. MODELO DE DIVERSIFICACIÓN....................................................................... 74
7.5. MODELO DE COORDINACIÓN......................................................................... 75
7.6. MODELO DE REPLICACIÓN.............................................................................. 77
7.7. ¿QUIÉN DEBE REALIZAR EL DISEÑO DE LA ARQUITECTURA EMPRESARIAL?..... 78
7.8. RESUMEN DEL TEMA....................................................................................... 79
8. SOA....................................................................................................................... 80
8.1. INTRODUCCIÓN AL CONCEPTO SOA.............................................................. 80
8.2. SERVICIOS....................................................................................................... 81
8.3. ARQUITECTURA SOA...................................................................................... 82
8.4. BENEFICIOS DE SOA........................................................................................ 83
8.5. EJEMPLO......................................................................................................... 85
8.6. RESUMEN DEL TEMA....................................................................................... 86
9. WEB SERVICES...................................................................................................... 87
9.1. HISTORIA........................................................................................................ 87
9.2. ESTÁNDAR WEB SERVICES.............................................................................. 89
9.3. JAVA Y SUN MICROSYSTEMS.......................................................................... 90
9.4. MICROSOFT Y .NET......................................................................................... 91
9.5. OTRAS ALTERNATIVAS..................................................................................... 93
9.6. CONCLUSIONES.............................................................................................. 94
9.8. RESUMEN DEL TEMA....................................................................................... 95
10. SEGURIDAD EN LOS NEGOCIOS........................................................................ 96
10.1. HISTORIA...................................................................................................... 96
10.2. EL PROCESO DE LA SEGURIDAD.................................................................... 98
10.3. NIVEL DIRECTIVO.......................................................................................... 98
10.4. POLÍTICAS DE SEGURIDAD............................................................................ 99
10.5. PROCEDIMIENTOS DE SEGURIDAD.............................................................. 100
10.6. HERRAMIENTAS DE SEGURIDAD.................................................................. 101
10.7. RESUMEN DEL TEMA................................................................................... 102
11. AMENAZAS Y VULNERABILIDADES................................................................ 103
11.1. LAS AMENAZAS.......................................................................................... 103
11.2. EL MÉTODO DE FUNCIONAR....................................................................... 105
11.3. CONCLUSIONES.......................................................................................... 108
11.4. RESUMEN DEL TEMA................................................................................... 109
12. MALWARE......................................................................................................... 110
12.1. INTRODUCCIÓN AL CONCEPTO DE MALWARE............................................ 110
12.2. MALWARE INFECCIOSO.............................................................................. 111
12.2.1 VIRUS................................................................................................... 111
12.2.2 GUSANOS............................................................................................. 113
12.3. MALWARE OCULTO..................................................................................... 113
12.3.1 TROYANO............................................................................................. 113
12.3.2 PUERTAS TRASERAS.............................................................................. 114
12.3.3 ROOTKITS............................................................................................. 114
12.3.4 DRIVE-BY-DOWNLOADS........................................................................ 114
12.4 MALWARE PARA OBTENER BENEFICIOS........................................................ 115
12.4.1 REALIZAR LLAMADAS TELEFÓNICAS O DIALER..................................... 115
12.4.2 MOSTRAR PUBLICIDAD......................................................................... 115
12.4.3 ROBAR INFORMACIÓN PERSONAL........................................................ 116
12.5. SOFTWARE DE PROTECCIÓN....................................................................... 116
12.5.1 ANTIVIRUS............................................................................................ 116
12.5.2 FIREWALL............................................................................................. 117
12.5.3 SENTIDO COMÚN................................................................................. 117
12.6. RESUMEN DEL TEMA................................................................................... 118
13. GESTIÓN DE UN ATAQUE................................................................................. 119
13.1 MODOS DE ATAQUE.................................................................................... 119
13.1.1 ATAQUES DESDE EL INTERIOR............................................................... 119
13.1.2 ATAQUES DESDE EL EXTERIOR.............................................................. 119
13.1.3 ATAQUES A EQUIPOS FÍSICOS............................................................... 120
13.1.4 ATAQUES DE INGENIERÍA SOCIAL......................................................... 120
13.2. MOTIVACIÓN PARA EL ATAQUE.................................................................. 120
13.3. EL ATAQUE.................................................................................................. 121
13.4. TIPOS DE ATAQUE....................................................................................... 121
13.4.1 DENEGACIÓN DE SERVICIO.................................................................. 121
13.4.2 SUPLANTACIÓN DE IDENTIDAD............................................................. 122
13.4.3 ANALIZADORES.................................................................................... 123
13.4.4 RASTREADORES.................................................................................... 123
13.4.5 DESBORDAMIENTO DE BUFFER............................................................. 123
13.5. REPUESTA................................................................................................... 124
13.6. RESUMEN DEL TEMA................................................................................... 125
14. EL FACTOR HUMANO....................................................................................... 126
14.1. ERRORES HUMANOS................................................................................... 126
14.2. OBJETIVOS.................................................................................................. 126
14.3. MOVILIDAD HUMANA................................................................................ 127
14.4. EJEMPLO DE POLÍTICAS............................................................................... 129
14.5. ESTABLECER AUDITORÍAS........................................................................... 132
14.6. RESUMEN DEL TEMA................................................................................... 132
15. CASO PRÁCTICO: SONY NETWORKS............................................................... 133
15.1. INTRODUCCIÓN AL CASO........................................................................... 133
15.2. CRONOLOGÍA DE UN ATAQUE.................................................................... 134
15.3. RESPUESTA DE SONY.................................................................................. 137
15.3.1 PRIMER COMUNICADO........................................................................ 137
15.3.2 SEGUNDO COMUNICADO.................................................................... 138
15.3.3 RUEDA DE PRENSA............................................................................... 138
15.4. CONSECUENCIAS........................................................................................ 139
15.5. ¿QUÉ SE PODRIA HABER HECHO DIFERENTE?............................................. 139
15.6. RESUMEN DEL TEMA................................................................................... 142
16. SEGURIDAD Y PRIVACIDAD............................................................................. 143
16.1. BIG DATA.................................................................................................... 143
16.2. COOKIES..................................................................................................... 144
16.3. PRIVACIDAD................................................................................................ 145
16.4. EJEMPLO DE EVOLUCIÓN DE PRIVACIDAD: FACEBOOK............................... 146
16.5. PRIVACIDAD EN LA EMPRESA...................................................................... 148
16.6. PRIVACIDAD Y PUBLICIDAD........................................................................ 149
16.7. CONCLUSIONES.......................................................................................... 149
16.8. RESUMEN DEL TEMA................................................................................... 149
17. CONFIANZA Y CONFIDENCIALIDAD EN MEDIOS DIGITALES......................... 150
17.1. COMERCIO ELECTRÓNICO.......................................................................... 150
17.2. CONFIDENCIALIDAD................................................................................... 152
17.2.1. PRIVACIDAD........................................................................................ 152
17.2.2. INTEGRIDAD........................................................................................ 153
17.2.3. AUTENTICIDAD.................................................................................... 153
17.2.4 NO REPUDIO......................................................................................... 153
17.3. CONCLUSIONES.......................................................................................... 154
17.4. RESUMEN DEL TEMA................................................................................... 155
18. SEGURIDAD EN LA NUBE................................................................................. 156
18.1. ANTECEDENTES.......................................................................................... 156
18.2. POLITICAS IMPRESCINDIBLES....................................................................... 158
18.3. ESTRATEGIA DE SALIDA.............................................................................. 160
18.4. CONCLUSIONES.......................................................................................... 161
18.5. RESUMEN DEL TEMA................................................................................... 161
19. SEGURIDAD EN TECNOLOGÍAS MÓVILES....................................................... 162
19.1. AMENAZAS MÓVILES.................................................................................. 162
19.1.1. MALWARE........................................................................................... 162
19.1.2. PÉRDIDA O ROBO................................................................................ 163
19.1.3. HERRAMIENTAS DE PAGO ELECTRÓNICO............................................ 164
19.2. ¿QUÉ PODEMOS HACER?........................................................................... 165
19.3. BYOD.......................................................................................................... 166
19.4. CONCLUSIONES.......................................................................................... 167
19.5. RESUMEN DEL TEMA................................................................................... 168
20. CÓMO ELABORAR UN PLAN DE SEGURIDAD................................................. 169
20.1. ANTECEDENTES.......................................................................................... 169
20.2. IDENTIFICAR LOS ACTIVOS.......................................................................... 170
20.3. RECURSOS DE IT ........................................................................................ 170
20.4. CONTROLAR EL ACCESO A LOS SISTEMAS.................................................. 171
20.5. SOFTWARE SEGURO.................................................................................... 172
20.6. CONOCER EL SOFTWARE............................................................................ 172
20.7. PROBAR Y COMPARAR............................................................................... 173
20.8. PREPARAR RESPUESTAS............................................................................... 174
20.9. ANALIZAR LAS CAUSAS.............................................................................. 175
20.10. RESUMEN DEL TEMA................................................................................. 176
21. PLAN DE SEGURIDAD....................................................................................... 177
21.1. ESCENARIO DE COMPETENCIA DEL GOBIERNO ELECTRÓNICO.................... 177
21.1.1. OBJETIVOS DEL GOBIERNO ELECTRÓNICO........................................... 178
21.2. DESCRIPCIÓN Y SERVICIOS DE MADRID.ORG.............................................. 179
21.3. OBJETIVOS DEL PLAN.................................................................................. 180
21.4. PRINCIPALES AMENAZAS............................................................................ 180
21.4.1. CONFIDENCIALIDAD............................................................................ 181
21.4.2. INTEGRIDAD........................................................................................ 181
21.4.3. DISPONIBILIDAD................................................................................... 181
21.4.4. AUTENTICIDAD.................................................................................... 181
21.4.5. TRAZABILIDAD..................................................................................... 182
21.5. ANÁLISIS DEL RIESGO.................................................................................. 182
21.5.1. CONFIDENCIALIDAD............................................................................ 182
21.5.2. INTEGRIDAD........................................................................................ 183
21.5.3. DISPONIBILIDAD................................................................................... 183
21.5.4. AUTENTICIDAD.................................................................................... 183
21.5.5. TRAZABILIDAD..................................................................................... 184
21.6. POLÍTICAS DE SEGURIDAD.......................................................................... 184
21.6.1. PROGRAMACIÓN EN APLICACIONES WEB........................................... 185
21.6.2. PROTOCOLOS WEB.............................................................................. 186
21.6.3. HERRAMIENTAS DE ANÁLISIS Y MANIPULACIÓN WEB......................... 186
21.6.4. ATAQUES SOBRE ENTORNOS WEB....................................................... 186
21.6.4.1. INYECCIÓN SQL................................................................................ 186
21.6.4.2. CROSS-SITE SCRIPTING (XSS)............................................................ 187
21.6.4.3. CROSS-SITE REQUEST FORGERY (CSRF)............................................. 187
21.6.5. MECANISMOS DE AUTENTICACIÓN Y AUTORIZACIÓN WEB................ 187
21.6.6. GESTIÓN DE SESIONES......................................................................... 187
21.6.7. GESTIÓN DEL ENTORNO FÍSICO........................................................... 187
21.7. PLAN DE CONTINUIDAD DEL NEGOCIO....................................................... 188
21.7.1. COSTE DE OPORTUNIDAD DE INTERRUPCIÓN DE SERVICIO................. 188
21.7.2. IDENTIFICACIÓN DE ELEMENTOS CRÍTICOS.......................................... 188
21.7.3. INCORPORACIÓN EQUIPAMIENTO DE RESPALDO................................. 189
21.7.4. ESTIMACIÓN DEL IMPACTO Y RIESGO RESIDUALES............................. 189
21.7.5. DISEÑO DEL PLAN DE RECUPERACIÓN................................................. 189
21.8. CONCLUSIONES.......................................................................................... 190
21.9. ANEXO ....................................................................................................... 190
21.10. RESUMEN DEL TEMA................................................................................. 197
22. GESTIÓN DEL RIESGO....................................................................................... 198
22.1. TÉRMINOS Y DEFINICIONES......................................................................... 198
22.2. LA GESTIÓN DEL RIESGO............................................................................. 198
22.2.1. TIPOS DE METODOLOGÍA DE ANÁLISIS DE RIESGO.............................. 198
22.2.1.1. METODOLOGÍAS CUALITATIVAS....................................................... 199
22.2.1.2. METODOLOGÍAS CUANTITATIVAS..................................................... 200
22.2.1.3. METODOLOGÍAS MIXTAS................................................................. 201
22.2.2. VALORACIÓN DE LOS RIESGOS............................................................ 202
22.2.2.1. ANÁLISIS DE RIESGOS....................................................................... 203
22.2.2.1.1. ACTIVOS........................................................................................ 204
22.2.2.1.2. AMENAZAS................................................................................... 210
22.2.2.1.3. IMPACTO Y NIVELES DE RIESGO.................................................... 214
22.2.2.2. EVALUACIÓN DE RIESGOS................................................................ 215
22.2.3. TRATAMIENTO DEL RIESGO.................................................................. 216
22.2.3.1. ACEPTACIÓN DEL RIESGO................................................................. 222
22.2.4. COMUNICACIÓN DEL RIESGO............................................................. 223
22.2.5. MONITORIZACIÓN Y REVISIÓN DEL RIESGO......................................... 225
22.3. RESUMEN DEL TEMA................................................................................... 227
23. HERRAMIENTAS DE RESPALDO....................................................................... 231
23.1. ANTECEDENTES.......................................................................................... 231
23.2. TECNOLOGÍAS DE BACKUP......................................................................... 233
23.2.1. BACKUP A CINTA................................................................................ 233
23.2.2 BACKUP A DISCO................................................................................. 234
23.2.3 SOFTWARE DE BACKUP........................................................................ 235
23.3. POLITICA DE SEGURIDAD EN LOS BACKUP.................................................. 236
23.3.1 HORARIO.............................................................................................. 236
23.3.2 VALIDACIÓN AUTENTIFICACIÓN........................................................... 236
23.4. CONCLUSIONES.......................................................................................... 237
23.5. RESUMEN DEL TEMA................................................................................... 238
24. HISTORIA DEL DESARROLLO E INTEGRACIÓN DE SISTEMAS........................ 239
24.1. INTRODUCCIÓN AL DESARROLLO E INTEGRACIÓN DE SISTEMAS................ 239
24.2. HISTORIA.................................................................................................... 241
24.2.1. PRIMER PERIODO................................................................................. 241
24.2.2. SEGUNDO PERIODO............................................................................. 242
24.2.3. TERCER PERIODO................................................................................. 242
24.2.4. CUARTO PERIODO............................................................................... 243
24.2.5. ACTUAL PERIODO................................................................................ 244
24.3. RESUMEN DEL TEMA................................................................................... 245
25. LENGUAJES DE PROGRAMACIÓN................................................................... 246
25.1. HISTORIA ................................................................................................... 246
25.2. DEFINICIÓN Y CLASIFICACIÓN.................................................................... 247
25.3. LENGUAJES................................................................................................. 251
25.4. ACTUALIDAD Y TENDENCIAS...................................................................... 252
25.5. RESUMEN DEL TEMA................................................................................... 252
26. METODOLOGÍAS DE DESARROLLO................................................................. 254
26.1. INTRODUCCIÓN A LAS METODOLOGÍAS DE DESARROLLO.......................... 254
26.2. TIPOS DE METODOLOGÍAS.......................................................................... 256
26.3. METODOLOGÍA LINEAL............................................................................... 257
26.4. METODOLOGÍA ITERATIVA.......................................................................... 259
26.5. METODOLOGÍA LINEAL-ITERATIVA.............................................................. 261
26.6. EJEMPLO..................................................................................................... 261
26.7. RESUMEN DEL TEMA................................................................................... 262
27. METODOLOGÍAS DE DESARROLLO ÁGIL: SCRUM......................................... 263
27.1. METODOLOGÍAS ÁGILES............................................................................. 263
27.2. SCRUM....................................................................................................... 265
27.2.1. EL FUNCIONAMIENTO DE SCRUM........................................................ 265
27.3. RESUMEN DEL TEMA................................................................................... 269
28. CMMI................................................................................................................. 271
28.1. INTRODUCCIÓN AL CONCEPTO DE CMMI.................................................. 271
28.2. ARQUITECTURA DEL MODELO.................................................................... 273
28.2.1. OBJETIVOS Y PRÁCTICAS GENÉRICOS ................................................. 273
28.2.2. OBJETIVOS Y PRÁCTICAS ESPECÍFICOS ............................................... 274
28.3. ÁREAS DE PROCESOS CMMI....................................................................... 274
28.4. NIVELES CMMI............................................................................................ 279
28.5. RESUMEN DEL TEMA................................................................................... 282
29. CASO PRÁCTICO: DESARROLLO DE UN NOVEDOSO SISTEMA
TECNOLÓGICO........................................................................................................ 283
29.1. CASO PRÁCTICO......................................................................................... 283
29.1.1. INFRAESTRUCTURA DE APLICACIONES ............................................... 283
29.1.1.1. SOLUCIÓN........................................................................................ 284
29.1.1.2. DESARROLLO.................................................................................... 284
29.1.1.3. DISEÑO............................................................................................. 284
29.1.1.4. CORREO ELECTRÓNICO.................................................................... 285
29.1.1.5. OFIMÁTICA....................................................................................... 285
29.1.1.6. SOFTWARE DE GESTIÓN UNIFICADA DE EMPRESA............................ 285
29.1.1.7. COMUNICACIONES.......................................................................... 285
29.1.1.8. CONCLUSIONES................................................................................ 285
29.2. RESUMEN DE APLICACIONES...................................................................... 286
29.2.1. AMAZON WEB SERVICES..................................................................... 286
29.2.2. DEBIAN................................................................................................ 286
29.2.3. UBUNTU.............................................................................................. 287
29.2.4. WINDOWS 7........................................................................................ 287
29.2.5. ECLIPSE................................................................................................ 288
29.2.6. GIT...................................................................................................... 288
29.2.7. BUGZILLA............................................................................................ 289
29.2.8. TOMCAT.............................................................................................. 289
29.2.9. BLUEFISH............................................................................................. 290
29.2.10. GOOGLE APPS................................................................................... 291
29.2.11. ASTERISK........................................................................................... 292
29.3.RESUMEN DEL TEMA.................................................................................... 293
30. TIPOLOGÍA DE APLICACIONES......................................................................... 294
30.1. DEFINICIÓN DE APLICACIÓN ...................................................................... 294
30.2. TIPOLOGÍA DE APLICACIONES .................................................................... 294
30.3. TENDENCIAS EN APLICACIONES.................................................................. 297
30.4. RESUMEN DEL TEMA................................................................................... 300
31. INTEGRACIÓN DE SISTEMAS........................................................................... 301
31.1. ARQUITECTURA DE SISTEMAS..................................................................... 301
31.2. INTEGRACIÓN DE SISTEMAS....................................................................... 302
31.3. PATRONES DE INTEGRACIÓN....................................................................... 305
31.3.1. PATRONES PRINCIPALES (BÁSICOS)...................................................... 305
31.3.2. EJEMPLO DE PATRONES DE INTEGRACIÓN........................................... 306
31.4. PROBLEMÁTICA DE LA INTEGRACIÓN......................................................... 307
31.5. HERRAMIENTAS DE INTEGRACCIÓN ETL...................................................... 313
31.5.1. EXTRACCIÓN....................................................................................... 313
31.5.2. TRANSFORMACIÓN............................................................................. 314
31.5.3. CARGA................................................................................................ 314
31.6. RESUMEN DEL TEMA................................................................................... 315
32. OPEN SOURCE.................................................................................................. 317
32.1. ANTECEDENTES ......................................................................................... 317
32.2. TIPOS DE LICENCIAS OPEN SOURCE............................................................ 318
32.3. OPEN SOURCE EN LAS EMPRESAS............................................................... 322
32.4. EJERCICIO: OFFICE VS. OPENOFFICE.ORG.................................................... 322
32.4.1. SOLUCIÓN........................................................................................... 323
32.4.2. CONCLUSIONES PERSONALES.............................................................. 324
32.5. RESUMEN DEL TEMA................................................................................... 326
BIBLIOGRAFÍA......................................................................................................... 327
GLOSARIO DE TÉRMINOS...................................................................................... 332
Centro Europeo de Postgrado Módulo. Gestión y Desarrollo de Sistemas
1. Criterios de selección
“Los negocios han pasado de estar organizados alrededor del flujo
de mercancías y dinero a estar organizados alrededor del flujo de
información dentro de las empresas.”
1.1. Criterios racionales

Este enfoque propone que la toma de decisiones se basa en el cálculo de la utilidad de la
innovación propuesta o de la aplicación a seleccionar, para poder hacer este cálculo se
han de tener en cuenta múltiples variables:
1. Identificando los objetivos de rendimiento necesarios para el correcto funcionamien-

to del sistema.
2. Analizando las diferentes alternativas tecnológicas disponibles de acuerdo a los obje-

tivos marcados (al resultado deseado).
3. Analizando las diferentes alternativas tecnológicas en relación a su coste (es decir, de

acuerdo a la inversión necesaria).
4. Seleccionando la alternativa con la relación más favorable entre la inversión y el ren-

dimiento (midiendo la utilidad real de la solución a seleccionar).
Teniendo en cuenta todas estas métricas, tendremos que valorar una serie de conceptos
diferentes, como el coste de propiedad. El Coste Total de Propiedad o Total Cost of Ow-
nership (TCO) es un concepto que fue popularizado por la consultora Gratner Group en el
año 1987 y que nos permite medir el valor de las inversiones necesarias para llevar a cabo
un proyecto de las tecnologías de la información y las comunicaciones.
Para poder medir el Coste Total de Propiedad es necesario establecer un periodo de tiem-
po a lo largo del cual se realizará la amortización de la inversión, normalmente esos tiem-
pos se suelen tomar entre tres o cinco años. Se deberán definir los diferentes conceptos
que integran el Coste Total de Propiedad del sistema a implantar y se ha de asegurar y
garantizar que las comparaciones se han de realizar entre sistemas con las bases iguales.
De igual forma que si vamos a comprar un coche y no nos decidimos entre dos soluciones
sería injusto valorar uno con los impuestos y gastos de matriculación incorporados y el
otro sin todos esos parámetros incluidos dentro del presupuesto, pues la balanza se incli-
naría claramente hacia uno de los dos lados.
09
De los tres elementos a incorporar (el periodo, los conceptos y las bases idénticas) el más
importante es el de la definición de los costes que se incluirán dentro del análisis.
Para ayudar a su cálculo de manera eficiente la consultora que creó el concepto, Gartner,
recomienda una metodología que incluye una serie de costes que divide entre costes di-
rectos e indirectos.
1.1.1 Costes directos

Entre los costes directos que tendremos para la puesta en marcha de un sistema dentro de
un proyecto de tecnologías de la información y las comunicaciones entrarán las inversio-
nes en compra, reparación y mantenimiento o actualización tanto de las partes hardware
de la solución como de los elementos de software de la solución, con todas sus licencias
necesarias.
Entrarán también todos los gastos operativos relacionados, aquellos que constan del gas-
to en personal técnico. Este suele ser uno de los mayores de todos los gastos, ya que los
gastos de personal tienen una gran importancia.
Los gastos administrativos son igualmente un concepto a tener en cuenta, dentro de lo

que serían los gastos directos, serán los gastos derivados de la auditoría, generación de
presupuestos o consultorías previas a la instalación.
1.1.2 Costes indirectos

Los costes indirectos son aquellos que no son tan sencillos de asignar al proyecto, pero
que son necesarios para poder medir el coste real del mismo, así tendremos costes que
pueden ir derivados de los propios usuarios, por los gastos en formación a los usuarios de
la nueva plataforma o por el tiempo perdido por las ayudas entre compañeros hasta llegar
a controlar la nueva herramienta.
Tendremos que tener en cuenta los costes derivados de la improductividad, bien en los
momentos de cambio de plataforma, o en aquellos entornos que implican asociar a su uso
un tiempo de parada programada o las futuras actualizaciones de los ordenadores, servi-
dores, la red, las impresoras o las propias aplicaciones.
En ocasiones, también deberíamos de considerar los costes indirectos también denomi-

nados costes ocultos, como pueden ser aquellos derivados de la alimentación o refrigera-
ción de los sistemas, el suelo que está ocupando (el suelo de las oficinas tiene un coste y
si es en un centro de datos, puede que más por las implicaciones técnicas que conlleva).
10
1.1.3 Otras mediciones de costes

Los asociados a los coses también pueden ser medidos de diferentes maneras como el
ROI o retorno de la inversión, que sería aquel que nos permite medir en qué momento del
uso del sistema, las ventajas que nos ofrece nos permite recuperar la cantidad invertida
en la adquisición.
Otro de los parámetros asociados a los costes que tendremos dentro de la plataforma y
que tendremos que tener en cuenta es el TTM o Time To Market, que sería aquel paráme-
tro que nos indica cuándo tendremos disponible el nuevo sistema que queremos instalar
dentro del entorno.
1.1.4 Calidad
Cuando estamos midiendo la calidad deberíamos tener en cuenta que este es un concep-
to bastante subjetivo, por lo que sería interesante marcar una serie de parámetros, como
serán la fiabilidad, rendimiento, escalabilidad, seguridad o la marca.
La fiabilidad es la capacidad de un sistema informático para dar servicio a un usuario de

forma ininterrumpida. La fiabilidad se mide a través de valores estadísticos que indican
la cantidad de minutos durante un año en que un sistema se encuentra disponible para
dar servicio. Así un 99,999% de disponibilidad nos indicará que el sistema está tan solo
parado durante cinco minutos en todo el año, este cálculo, si lo hacemos igualmente con
el número de minutos al año será de (365*24*60) que serán 525600 minutos a lo largo del
año. Esta medida se llama downtime o falta de disponibilidad del sistema.
El rendimiento es la medida de la velocidad de respuesta de un sistema operativo o de

un sistema informático ante la demanda de una tarea determinada. El rendimiento de
un sistema operativo, por ejemplo, se realizará en relación al software de aplicación que
se utiliza y en la relación del sistema operativo con el hardware disponible para hacerlo
funcionar. De esta manera, al realizar las medidas, es importante que los sistemas infor-
máticos sean lo más equivalentes posibles, sino iguales.
La escalabilidad será la capacidad de un sistema para adaptarse a una demanda crecien-

te de servicios, por ejemplo, un rad escalable sería aquella que empieza con dos nodos y
pueda ser fácilmente expandida a miles de nodos. Es una de las características más im-
portantes en las evaluaciones de sistemas informáticos, ya que, si los sistemas carecen de
escalabilidad, muchas veces pueden hacer morir el mismo antes de tiempo si se produce
un éxito dentro del funcionamiento, o si hablamos de un entorno de Internet, si no consi-
deramos que pueda crecer, estaremos condenando a nuestro sistema al fracaso desde el
momento inicial.
11
La seguridad de los sistemas informáticos podría venir definida por el conjunto de téc-
nicas para proteger la integridad de los datos almacenados en un sistema, permitiendo
su consulta o modificación en función de un conjunto de permisos y restricciones. Este
concepto es también importante en los procesos de envío y recepción de datos, donde se
puede llegar a utilizar técnicas de encriptación. Un parámetro a tener en cuenta es que
la seguridad absoluta no existe y solo podemos trabajar en disminuir la probabilidad o
impacto de las situaciones no deseadas asociadas a la seguridad.
La marca, nombre, término, signo, símbolo o diseño, o la combinación de todos estos es la

manera de identificar los bienes o servicios de un vendedor o un grupo de vendedores y
diferenciarlos de los competidores. Como se ve en otros aspectos empresariales, la marca
representa un valor intangible que hace referencia a la seguridad que nos da, la atención
y los niveles de soporte que nos puede ofrecer un proveedor. Construir una marca no es
una labor fácil, requiere mucha inversión publicitaria y presencia constante en el mercado
con una calidad demostrada a lo largo del tiempo.
1.1.5 Factores de bloqueo

Las inversiones tecnológicas suelen llevar aparejadas un componente de coste que se va
a reflejar cuando se produzca un cambio tecnológico dentro de los sistemas.
Se tratan estos costes de cambio, dado que cuanto mayores sean, más dificultan al usuario
sustituir una tecnología por otra, llevándonos a una situación de lock-in o bloqueo.
Cuando el coste de transición entre dos tecnologías dadas es elevado, resulta complicado
cambiar una tecnología por otra y la compañía se ve en esa posición de bloqueo. El blo-
queo puede darse tanto al nivel de la solución tecnológica como al nivel del proveedor
tecnológico.
Se pueden dar bloqueos tanto internos como externos, por ejemplo, si hablamos de blo-
queos a nivel interno, nos podemos encontrar con contratos que, en un momento dado,
la dirección decidió firmar un contrato de largo plazo con un proveedor tecnológico con-
creto.
Otra situación de bloqueo interno se puede dar cuando se realizan grandes inversiones
en aplicaciones e infraestructuras esenciales que son heredadas de antes. Se pueden pro-
ducir también como característica de bloqueo por parte de la propia compañía aquellas
relacionadas con la resistencia del usuario final a emplear nuevas aplicaciones debido a
la dificultad asociada con aprender a manejar y llegar a controlar las nuevas herramientas.
12
Se pueden dar también situaciones de bloqueo externo, como que exista un monopolio
que haga que el poder de negociación y control del fabricante sobre la evolución de la
tecnología nos obliguen como selectores de la tecnología para nuestro sistema.
Estos costes pueden ser afrontados de manera directa por parte de la empresa, si habla-
mos de esos costes directos, como los que van asociados con la formación del personal, la
migración de los datos, la adaptación de programas y otras aplicaciones, etc.
Si los costes son de los considerados indirectos, los soportará el proveedor de la nueva
tecnología a la que queramos migrar, por ejemplo, los incentivos que ofrezcan para ayudar
al cambio de esa tecnología propuesta por el líder del mercado hacia la nueva tecnología.
1.2. Criterios derivados del entorno

La teoría de la difusión de la innovación, que desarrollo Roger, afirma que además de los
caculos de utilidad y coste, existen una serie de aspectos importantes que influyen en las
decisiones de las empresas a la hora de adoptar nuevas tecnologías. Estas cinco propie-
dades son las siguientes:
• Ventaja relativa: deberíamos ver si el sistema nuevo es realmente mejor que aquel
al que sustituye y en qué riesgos implícitos incurriremos en caso de sustituir al
sistema anterior.
• Posibilidad de observación: si serán visibles estos nuevos resultados o las mejoras

que acarrea por parte de la organización. De igual modo deberíamos comprobar si
se apreciará el funcionamiento del nuevo sistema y si impactará en los procesos y
resultados empresariales.
• Compatibilidad: será importante determinar si el nuevo sistema será compatible

y se adaptará a la política de la compañía, así como a las infraestructuras tecnoló-
gicas ya existentes dentro de la empresa.
• Complejidad: deberíamos tener en consideración si el sistema resultara sencillo

de comprender y aprender a utilizar y si el personal del que disponemos actual-
mente tiene la capacidad de aplicar y mantener el propio sistema.
• Posibilidad de prueba: en muchos casos, para ayudar a la adopción de una nueva

tecnología es interesante el poder realizar pruebas piloto antes de aplicar el siste-
ma dentro de la empresa de manera definitiva.
El proceso de difusión, por norma general, es lento, de esa forma durante la primera fase
de adopción tendrá pocos usuarios, y va cobrando fuerza a medida que aumenta el núme-
ro de usuarios, lo cual crea cierto grado de incertidumbre que influye en los resultados de
la inversión.
13
La incertidumbre es una característica habitual en los sectores emergentes y en aquellos

que hacen un amplio uso de la tecnología. A medida que el cambio tecnológico es más
radical o complejo se hace más necesaria formación al usuario final, lo cual provoca una
mayor incertidumbre sobre la adopción del proceso, lo cual puede dificultar la adopción
de la nueva tecnología, aunque esta sea claramente superior a su predecesora.
Por este motivo las adopciones de nuevas tecnologías influyen en la cultura de la compa-
ñía y al revés, compañías innovadoras acogerán con más facilidad innovaciones tecnoló-
gicas.
Así, la adopción de nuevas tecnologías puede verse limitada si existen barreras de co-
nocimiento dentro de la compañía. La adopción de tecnologías complejas supone una
carga de aprendizaje, sobre todo cuando resulta complicado resolver problemas técnicos,
lo cual aumenta la sensación de que la inversión realizada es irreversible.
Otro factor que influye en las decisiones de los ejecutivos, desde el punto de vista de la
cultura de la organización, es la incertidumbre. Es imposible predecir el éxito de la aplica-
ción de una innovación tecnológica, por lo que cada compañía debe de tomar la decisión
basándose en sus experiencias y expectativas.
Así pues, las decisiones sobre la adopción de una determinada tecnología varían en fun-
ción del grado de aversión al riesgo que tenga el o los que toman la decisión.
El riesgo asociado a las decisiones también depende del grado de flexibilidad que permi-
tan los presupuestos de las compañías a la hora de experimentar durante un cierto perio-
do de tiempo con dicha innovación, para comprobar su conveniencia antes de adoptarla
definitivamente.
Otro aspecto a tener en cuenta para la difusión de la tecnología, será la demanda de la

misma, así a medida que aumente el número de usuarios aumentará la demanda de la
tecnología y su valor en el mercado. De manera directa lo podemos ver en sistemas am-
pliamente extendidos que tienen una gran red de usuarios y por lo tanto existe demanda
de los mismos como el correo electrónico o los teléfonos móviles, o también la relación
entre sus complementos, así para decidirnos por un televisor en 3D miraremos el número
de películas que podremos visionar en el mismo, para ver si nos interesa.
Dato importante
Cuando el coste de transición entre dos tecnologías es elevado, es complicado cam-

biar una tecnología por otra y la compañía se ve en posición de bloqueo. El bloqueo
puede darse al nivel de la solución tecnológica y/o al nivel del proveedor tecnoló-
gico.
14
1.3. Criterios influenciables

Dentro de los criterios de selección existen también parámetros que entran más a fondo
en el campo de la psicología, como que en muchas ocasiones las decisiones no se toman
de forma racional, o siguiendo la teoría de la difusión, sino que entran en juego las in-
fluencias sociales y los prejuicios.
Las empresas no toman las decisiones de manera aislada, por el contrario, se controlan los
movimientos de los competidores e incluso en ocasiones entran en contacto para inter-
cambiar información pertinente a la toma de decisiones.
La dinámica, por lo tanto, entra en la toma de decisiones cuando el que decide toma la
decisión basándose en criterios de terceras personas.
La imitación entre compañías provoca que cuanto más extendida esté una tecnología
dentro del sector, tanto más será la presión para la empresa que ha de tomar la decisión
de adoptarla, ignorando sus necesidades propias e imitando al resto.
De idéntica forma, si las grandes empresas optan por una innovación, es habitual una
oleada de adopción de esa tecnología por parte de empresas que no estén teniendo tan
buenos resultados y busquen una forma de adoptarlo.
En la vida cotidiana, como usuarios hemos visto multitud de casos donde una tecnología
era adoptada no por ser la mejor, sino la que tenían nuestros amigos (de pequeños al ir
al colegio por unas zapatillas o un balón de futbol) igualmente nos pasa en el mundo
empresarial.
1.4. Conclusiones
En los procesos de toma de decisiones influyen múltiples factores, y el conocerlos nos
ayudará a amoldarnos a dicha toma de decisiones, así será necesario un estudio racional
y medido de las ventajas o desventajas de cada tecnología.
Pero si hay algo que no podemos dejar de lado como personas es la existencia de factores
externos que nos pueden incitar a decantarnos por una u otra solución, aunque los facto-
res racionales no nos la marquen como la mejor. Así en el sector de la tecnología existía
el dicho de a nadie han despedido por contratar XXX, aunque los factores decisivos no
estuvieran a su favor.
1.5. Resumen del tema

En esta unidad hemos visto los distintos factores a tener en cuenta a la hora de realizar
una selección de tecnología, costes directos, indirectos, ROI, TCO, TTM y los aspectos
derivados de la influencia del entorno que pueden influir en la decisión.
15
2. Virtualización de servidores
“Las características tecnológicas del mercado de servidores hacen
que lo primero sea la garantía de que las aplicaciones que se quie-
ren ejecutar se puedan hacer de manera segura y garantizando la
disponibilidad de los sistemas.”
2.1. Introducción a la virtualización de servidores

La virtualización nace como una tecnología de software que permite reutilizar o reapro-
vechar una infraestructura hardware dada. Es un concepto que se viene utilizando en el
mundo de las tecnologías de la información desde los años 60, en los que, con la creación
de los primeros centros de datos, se planteaba la necesidad o la posibilidad de reaprove-
char la misma máquina para más de un propósito de manera simultánea.
La virtualización, con la creación de los entornos de cliente servidor y el mundo de los

PC (ordenadores personales) quedó prácticamente relegada a entornos de prueba o de-
sarrollo, también conocidos como emuladores, para que en un sistema se pudieran hacer
pruebas de funcionamiento de otros diferentes, para comprobar o garantizar su funcio-
namiento.
Posteriormente, ese entorno de emulador dio paso a unos sistemas que permitían la eje-
cución de aplicaciones independientemente del entorno donde se quisieran plantear, así
con este objeto nacen herramientas como las máquinas virtuales de Java que permiten
ejecutar el mismo código o aplicación independientemente del entorno, sistemas que tu-
vieron gran despliegue con Internet, ya que independiente de el sistema desde el que se
accediera, la aplicación se comportaría de la misma forma.
A finales de la década de los 90, comenzaron una serie de desarrollos que nuevamente
retomaron el nombre de la virtualización, enfocados a generar una máquina completa que
pudiese ser ejecutada dentro de otra de manera concurrente y permitiendo, por lo tanto,
ejecutar múltiples aplicaciones dentro del entorno.
16
Figura 1. Modelo de expectativas de Gartner: evolución de la virtualización.

Fuente: elaboración propia.
En la actualidad, todos los elementos de una infraestructura pueden funcionar de manera

virtual. A lo largo de la presente unidad didáctica veremos distintos sistemas de virtuali-
zación, cómo distinguirlos o seleccionar, así como las actuales tendencias de mercado en
las diferentes áreas:
• Virtualización de servidores.
• Virtualización de puestos de trabajo, con sus diferentes versiones, de aplicaciones,

de escritorio o de usuario.
• Virtualización del almacenamiento.
• Virtualización de las redes.
• Aprovechamiento de las tecnologías para el BYOD. (Bring Your Own Device, utili-
zar dispositivos propios de los usuarios en lugar de puestos por la empresa).
17
Figura 2. Árbol de trayectorias tecnológicas: trayectorias de la virtualización:

Asimismo, plantearemos los principales competidores de cada una de las áreas, así como
mencionar algunos que se aproximan a estas para poder conocer y distinguir las tecnolo-
gías y ayudar a una futura selección de la mejor en cada caso.
La virtualización, por lo tanto, ya se puede considerar una tecnología ampliamente exten-

dida en el mercado, con grandes ratios de penetración, y una de las variables a tener en
cuenta dentro del diseño de cualquier infraestructura tecnológica.
La virtualización es una solución que nos permite aprovechar al máximo los servidores,
que pasan de tener una ocupación media alrededor del 20% en casos tradicionales a con-
seguir al incorporar varias máquinas virtuales en el mismo sistema ocupaciones medias
superiores, lo que permite un mayor retorno de la inversión y reducir la necesidad de
tantos distintos sistemas.
Otra ventaja que nos ofrece la virtualización sería el despliegue más rápido de sistemas,
que se pueden poner en marcha de una forma sencilla y rápida y partiendo de una planti-
lla prediseñada tener un nuevo servidor funcionando en cuestión de minutos.
18
2.2. Virtualizacion de servidores

Actualmente, cuando en el mundo empresarial nos referimos a la virtualización, común-
mente se entiende la virtualización de servidores, es una de las facetas que más ha crecido
en implantación en el mercado y la práctica totalidad de las empresas tienen o se han
planteado un proyecto de virtualización de servidores.
Aunque ya nació hace más de 50 años, no fue hasta la llegada de procesadores más rápi-
dos y con múltiples núcleos de procesamiento que la industria no comenzó a implantarlo.
Los servidores estándares, basados en tecnología x86 han ido creciendo dentro de las em-
presas, en parte debido a las características o requisitos de cada aplicación lo hacían com-
plicado, sino imposible utilizar la misma máquina para más de una aplicación o sistema.
Con la aparición de servidores cada vez más potentes en las empresas, se empezó a ver
qué gran cantidad de los recursos se encontraban infrautilizados, pero que al ser incom-
patibles no permitía ponerse más de una aplicación sobre el mismo hardware, incremen-
tando los costes de adquisición y mantenimiento de los mismos.
Así una tecnología que nació para ayudar a los entornos de diseño y de pruebas, poco a
poco se ha ido generalizando en su utilización dentro de las empresas.
19
Al principio, la tecnología que permitía crear dentro de nuestra máquina, con el sistema
operativo instalado, otra que emulaba a una real para realizar las pruebas necesarias.
En la actualidad, lo que se hace es que un sistema llamado hipervisor se sitúa como plata-
forma de administración de los recursos de la máquina, permitiendo crear por encima de
este hipervisor múltiples máquinas que funcionan de manera totalmente independiente.
Necesitaremos un entorno que nos permita administrarlo, pero a cambio dota a la in-
fraestructura de una serie de ventajas que permiten agilizar y aprovechar al máximo la
infraestructura hardware de la compañía como pueden ser:
• Movimiento de máquinas.
• Alta disponibilidad
• Gestión de recursos
• Tolerancia a fallos
• Recuperación de sede.
2.2.1. Movimiento de máquinas

El movimiento de máquinas virtuales es una de las cualidades inherentes a la creación
de los entornos de virtualización de servidores que conllevan un conjunto de servidores y
permiten que la máquina virtual se ejecute de manera indiferente en uno o en otro servi-
dor, realizando el cambio de servidor en caliente, sin que los servicios asociados se vean
afectados.
Una necesidad de este entorno es por lo tanto la creación de un cluster que haga que los
servidores huésped o host estén conectados entre sí, para ser capaces de comunicarse de
manera constante y así pasar la información correspondiente a la máquina virtual entre
ellos y tengan componentes comunes como el espacio de almacenamiento de las máqui-
nas virtuales.
20
El entorno quedaría por lo tanto de la siguiente manera:
Figura 3. Infraestructura de virtualización.

Al estar ambos servidores o host conectados al mismo almacenamiento y tener, por lo

tanto, acceso a los datos de la máquina virtual, lo que define cuál de los dos está ejecután-
dola en un momento dado es quién es el poseedor de la memoria y puede pasar de uno
a otro a través de la red, pudiéndose producir este movimiento durante la ejecución sin
afectar a los servicios. Esto ofrecerá otra serie de beneficios asociados.
2.2.2. Alta disponibilidad

La alta disponibilidad de las máquinas virtuales viene dada por la gestión de recursos
que realiza una solución de cluster. Al final la máquina virtual será un servicio que se está
ejecutando en uno o en otro servidor según el momento.
La definición de máquina virtual nos permite que, si la máquina anfitrión o host donde se
está ejecutando se parara por el motivo que fuera, la otra sería capaz a través de la red de
detectar esta caída y recuperar el servicio.
21
Esta cualidad nos va a permitir garantizar que, si en un momento dado se produjese una
caída, el tiempo que se tarda en recuperar la aplicación que estuviera funcionando en la
máquina virtual sería el que tarde la máquina virtual en reiniciarse en el nuevo anfitrión,
permitiéndonos plantearnos la recuperación del otro anfitrión con más calma.
2.2.3. Gestión de recursos

La gestión de recursos dentro de las máquinas virtuales es una característica que nos va
a permitir grandes ahorros y una mayor optimización de los recursos.
Desde el momento en que somos capaces de reubicar las máquinas virtuales según lo que
nos interese, podemos plantear que con una monitorización constante del host podemos
estar recolocando sobre qué anfitrión se está ejecutando cada máquina virtual para que
estas funcionen de manera más eficiente, o bien por qué elegimos durante periodos de
tiempo con baja carga de trabajo redistribuir las máquinas virtuales para apagar algunos
host o huéspedes.
2.2.4 Tolerancia a fallos

Al estar dentro de un cluster de computación, las máquinas nos dan una cierta alta dispo-
nibilidad al ser capaces de recuperarse frente a caídas inesperadas del sistema, pero en
ocasiones esto puede no ser suficiente.
Existen entornos donde recuperarse de una caída implica un tiempo de parada de cinco
o diez minutos, algo que puede llegar a considerarse insuficiente para el sistema que se
esté ejecutando.
En este tipo de entornos, tradicionalmente se establecía un cluster, de tal manera que el

servicio se recuperaba de manera casi inmediata en el servidor adyacente.
Sin embargo, posicionar un cluster dentro de otro cluster, tiene menos sentido, ya que la
complejidad de control y gestión del mismo aumenta exponencialmente.
Para solucionar este inconveniente, algunos sistemas de virtualización (los más avanza-
dos) permiten la creación de una máquina virtual espejo, que se está ejecutando constan-
temente en la máquina servidor de al lado, para que, en caso de caída de un servidor, la
otra sea capaz de ponerse activa de forma inmediata.
Esta práctica tiene una serie de limitaciones, como evitar el movimiento de las máquinas
virtuales o las características de las mismas, pero a cambio incrementa enormemente la
disponibilidad de las mismas.
22
2.2.5 Recuperación de sede

Si estamos ejecutando las máquinas virtuales en un servidor que pertenece a un cluster
y tenemos características que dotan al sistema de tolerancia a fallos tales como la alta
disponibilidad o la recuperación de máquina por fallo, nos quedaría crear un entorno de
tolerancia frente a desastres.
La tolerancia frente a desastres en los entornos de virtualización se establece realizando

una sincronización del almacenamiento que tengamos en un centro de datos y la que
tengamos en otro, una vez que hacemos esto, el entorno de virtualización debe conocer
qué máquinas virtuales se están ejecutando en cada almacenamiento, para, en caso de
producirse una caída del sistema, ser capaces de recuperarse.
2.3. Grandes opciones

En la actualidad, esta opción de poder virtualizar los servidores ha hecho que práctica-
mente todos los grandes desarrolladores de software empresarial en cierta medida se ha-
yan lanzado de lleno a ofrecer sus soluciones. Sin embargo, de forma tal vez sorprendente,
el líder no es ninguna de estas soluciones, sino que lo es la compañía que relanzó este
mercado.
VMWare es quien a finales de los 90 volvió a introducir la virtualización, más como una
solución para el desarrollo de aplicaciones, aunque posteriormente pasó a ofrecerla como
un sistema de aprovechamiento del hardware que cada vez se volvía más potente y per-
mitía tener una reutilización del mismo, particionando las máquinas.
VMWare es una compañía que fue adquirida por un gran fabricante de almacenamiento
en el año 2004, pero fue dejada como compañía independiente para permitirle seguir cre-
ciendo, en el año 2012 sigue siendo el líder del mercado de la virtualización de servidores
con su versión vSphere 5.
Propone un sistema de virtualización que permite todas las características descritas en

el anterior capítulo y es quien va innovando y ofreciendo más componentes novedosos
dentro de los sistemas.
Ofrece un hipervisor, que funciona de manera independiente en la máquina, con una pe-
queña consola de gestión y que se agrega dentro de un cluster de virtualización para
ser gestionado por un software externo, llamado vCenter, que puede ser ejecutado en
una máquina virtual independiente, generalmente se suele posicionar sobre un Sistema
Operativo Microsoft Windows, aunque puede funcionar de manera autónoma sobre una
máquina virtual.
23
La última versión del hipervisor es un primer paso hacia lo que se puede considerar un
sistema operativo para el mundo de Internet, lo que han dado en llamar un sistema ope-
rativo de cloud. El software de gestión también evoluciona en ese sentido, tratando de
ofrecer la posibilidad de tener un entorno de automatización y gestión tal que la creación
de nuevas máquinas virtuales o nuevas instancias se realice de la manera más automati-
zada posible.
El máximo competidor de VMWare en el mundo de la virtualización es Microsoft. Micro-

soft como en muchos otros aspectos del mundo de la informática, no ha sido el primero
en llegar, pero sí que es una gran empresa de software que desarrolla rápido y consisten-
temente.
Si en los primeros momentos de la virtualización, en los años 90 y principios de la década

del 2000 se veía la virtualización como un elemento accesorio, llegando a crear sistemas
de virtualización tales como Virtual PC, ya a finales de la década se dio cuenta del po-
tencial de la tecnología y la importancia dentro de las empresas y pese a llevar mucho
terreno perdido frente a VMWare, trató de lanzar sistemas de virtualización que pudieran
competir.
Su primera aproximación seria a los entornos de virtualización se dio con el Hyper-V que
venía integrado como un rol dentro del Windows Server 2008, sin embargo, carecía de
muchas características, lo que resolvieron con la segunda versión integrada dentro del
2008 R2.
La aproximación por parte de Microsoft es menos ambiciosa en cuanto a tecnología que

la de VMWare, y lo que ofrecen es aquellos aspectos tecnológicos que se consideran real-
mente importantes, a cambio de un precio mucho más económico.
El Hyper-V es una utilidad gratuita que se incluye dentro del Windows 2008 R2 sin coste
adicional o instalarlo de manera independiente sin coste adicional. Algunas característi-
cas como la alta disponibilidad o movimiento de máquinas en caliente están incluidos.
El lanzamiento por parte de Microsoft de Windows Server 2012 incluye una nueva ac-
tualización de su Sistema Operativo de Virtualización, de su hipervisor, que le permite
incorporar más características tecnológicas.
Las mayores características a tener en cuenta a la hora de seleccionar un sistema de vir-

tualización, evidentemente, incluyen en primer lugar, la posibilidad de virtualizar el con-
junto de aplicaciones que vayamos a ejecutar por encima, como Bases de datos o nuestro
sistema de ERP (Enterprise Resource Planning, Software de Gestión Empresarial) si así
lo decidimos.
24
Otro punto que debemos de considerar es el coste de la solución, ya que según qué vaya-
mos a virtualizar y cómo queramos funcionar, puede haber grandes diferencias de coste
entre una solución u otra, hemos de ver que los costes de las licencias son variables, en
función del número de máquinas físicas, máquinas virtuales, memoria del host (servi-
dores de virtualización) número de cores que tenga nuestra plataforma, herramienta de
gestión de la virtualización a utilizar…
Las soluciones pueden diferir en características técnicas avanzadas y en el rendimiento

que puedan dar de una aplicación a otra, por lo que es interesante hacer un estudio deta-
llado de las características.
Entre VMWare y Microsoft tienen la mayor parte del mercado de la virtualización, no son
los únicos desarrolladores. Existen otras empresas desarrolladoras de software que no
estaban en el mundo de los Sistemas Operativos, que sin embargo se han metido en el
mundo de la virtualización como pueden ser:
• Citrix: Citrix adquirió una compañía que formaba parte del conglomerado de de-
sarrollo de virtualización alternativo como era Xen Server, que desarrollaba junto
con otras compañías como Red Hat, SUSE, IBM o HP el sistema de virtualización
Xen, que finalmente el resto de compañías fueron desarrollando por su parte, de-
jando el “estándar” de Xen para Citrix, que con su Citrix Xen Server pasa a tener
otra opción de virtualización, que permite una alternativa real al duopolio de vir-
tualización representado por Microsoft y VMWare. Aunque en el siguiente tema
veremos más características, ya que es un fuerte jugador en soluciones de virtuali-
zación orientadas a los terminales de cliente.
• Oracle: Oracle, tras la adquisición de varias compañías de software, ha ido adqui-

riendo varios sistemas de virtualización, como puede ser Virtual Iron o Sun Mi-
crosystem, para llegar a Oracle VM, fruto de la integración tanto de las tecnologías
de unos fabricantes como de otros y tratar de integrarlo con las tecnologías que
van desarrollando.
También los fabricantes de Sistemas Operativos como pueden ser Red Hat o SUSE optan
por sus versiones de virtualización, actualmente casi no se puede entender un sistema
operativo sin una opción de virtualización.
Red Hat tiene una opción que sería KVM que para la comunidad Linux es visto como
una opción, dado que viene avalado por un desarrollador de la talla de Red Hat, que ante-
riormente desarrollaba dentro del consorcio de Xen, pero que finalmente se decidió por
realizar su propia apuesta.
25
La última versión del hipervisor es un primer paso hacia lo que se puede considerar un
sistema operativo para el mundo de Internet, lo que han dado en llamar un sistema ope-
rativo de cloud. El software de gestión también evoluciona en ese sentido, tratando de
ofrecer la posibilidad de tener un entorno de automatización y gestión tal que la creación
de nuevas máquinas virtuales o nuevas instancias se realice de la manera más automati-
zada posible.
El máximo competidor de VMWare en el mundo de la virtualización es Microsoft. Micro-

soft como en muchos otros aspectos del mundo de la informática, no ha sido el primero
en llegar, pero sí que es una gran empresa de software que desarrolla rápido y consisten-
temente.
Si en los primeros momentos de la virtualización, en los años 90 y principios de la década

del 2000 se veía la virtualización como un elemento accesorio, llegando a crear sistemas
de virtualización tales como Virtual PC, ya a finales de la década se dio cuenta del po-
tencial de la tecnología y la importancia dentro de las empresas y pese a llevar mucho
terreno perdido frente a VMWare, trató de lanzar sistemas de virtualización que pudieran
competir.
Su primera aproximación seria a los entornos de virtualización se dio con el Hyper-V que
venía integrado como un rol dentro del Windows Server 2008, sin embargo, carecía de
muchas características, lo que resolvieron con la segunda versión integrada dentro del
2008 R2.
La aproximación por parte de Microsoft es menos ambiciosa en cuanto a tecnología que

la de VMWare, y lo que ofrecen es aquellos aspectos tecnológicos que se consideran real-
mente importantes, a cambio de un precio mucho más económico.
El Hyper-V es una utilidad gratuita que se incluye dentro del Windows 2008 R2 sin coste
adicional o instalarlo de manera independiente sin coste adicional. Algunas característi-
cas como la alta disponibilidad o movimiento de máquinas en caliente están incluidos.
El lanzamiento por parte de Microsoft de Windows Server 2012 incluye una nueva ac-
tualización de su Sistema Operativo de Virtualización, de su hipervisor, que le permite
incorporar más características tecnológicas.
Las mayores características a tener en cuenta a la hora de seleccionar un sistema de vir-

tualización, evidentemente, incluyen en primer lugar, la posibilidad de virtualizar el con-
junto de aplicaciones que vayamos a ejecutar por encima, como Bases de datos o nuestro
sistema de ERP (Enterprise Resource Planning, Software de Gestión Empresarial) si así
lo decidimos.
26
Otro punto que debemos de considerar es el coste de la solución, ya que según qué vaya-
mos a virtualizar y cómo queramos funcionar, puede haber grandes diferencias de coste
entre una solución u otra, hemos de ver que los costes de las licencias son variables, en
función del número de máquinas físicas, máquinas virtuales, memoria del host (servi-
dores de virtualización) número de cores que tenga nuestra plataforma, herramienta de
gestión de la virtualización a utilizar…
Las soluciones pueden diferir en características técnicas avanzadas y en el rendimiento

que puedan dar de una aplicación a otra, por lo que es interesante hacer un estudio deta-
llado de las características.
Entre VMWare y Microsoft tienen la mayor parte del mercado de la virtualización, no son
los únicos desarrolladores. Existen otras empresas desarrolladoras de software que no
estaban en el mundo de los Sistemas Operativos, que sin embargo se han metido en el
mundo de la virtualización como pueden ser:
• Citrix: Citrix adquirió una compañía que formaba parte del conglomerado de de-
sarrollo de virtualización alternativo como era Xen Server, que desarrollaba junto
con otras compañías como Red Hat, SUSE, IBM o HP el sistema de virtualización
Xen, que finalmente el resto de compañías fueron desarrollando por su parte, de-
jando el “estándar” de Xen para Citrix, que con su Citrix Xen Server pasa a tener
otra opción de virtualización, que permite una alternativa real al duopolio de vir-
tualización representado por Microsoft y VMWare. Aunque en el siguiente tema
veremos más características, ya que es un fuerte jugador en soluciones de virtuali-
zación orientadas a los terminales de cliente.
• Oracle: Oracle, tras la adquisición de varias compañías de software, ha ido adqui-

riendo varios sistemas de virtualización, como puede ser Virtual Iron o Sun Mi-
crosystem, para llegar a Oracle VM, fruto de la integración tanto de las tecnologías
de unos fabricantes como de otros y tratar de integrarlo con las tecnologías que
van desarrollando.
También los fabricantes de Sistemas Operativos como pueden ser Red Hat o SUSE optan
por sus versiones de virtualización, actualmente casi no se puede entender un sistema
operativo sin una opción de virtualización.
Red Hat tiene una opción que sería KVM que para la comunidad Linux es visto como
una opción, dado que viene avalado por un desarrollador de la talla de Red Hat, que ante-
riormente desarrollaba dentro del consorcio de Xen, pero que finalmente se decidió por
realizar su propia apuesta.
27
3. Virtualización y otras tecnologías

“La virtualización nos permite abstraernos del entorno físico don-
de estamos funcionando para ofrecernos un mundo de software in-
dependiente.”
3.1. Virtualización del almacenamiento

El almacenamiento en las empresas es un entorno cada vez más conflictivo, ya que se
requiere mucho espacio, se genera mucha información y hemos de ser capaces de tratarlo
rápidamente.
A la hora de gestionar el almacenamiento, lo primero que nos viene a la cabeza es un

disco duro o un sistema como puede ser una memoria Flash o un CD/DVD. El almacena-
miento empresarial en base no difiere demasiado de esas ideas, la diferencia es cómo lo
tratamos o gestionamos para conseguir la máxima disponibilidad y capacidad, es decir,
tener el máximo espacio y al mismo tiempo garantía de que va a funcionar.
A la hora de gestionar todo ese almacenamiento, lo que nos encontramos es con sistemas
que contienen muchos discos, que con múltiples tecnologías pueden proteger la infor-
mación, pero cada vez es más interesante que esa protección y gestión del mismo sea
transparente para el sistema y podamos ir añadiendo capacidad y distintas tecnologías de
almacenamiento, más rápido, más barato o con más capacidad y el sistema se encargue de
gestionarlo, creando un gran entorno virtual del que nosotros iremos cogiendo el espacio
que necesitemos.
Existe una máxima en la virtualización que nos permitía ir más rápido y es: cuantos más
discos tengamos, más rápido escribimos y leemos la información, ya que disponemos de
más cabezas escribiendo o buscando los datos.
Los sistemas de virtualización del almacenamiento nos permiten que la máquina escriba
en múltiples discos al mismo tiempo, pero presente hacia el exterior uno o varios discos
según la necesidad que tengamos.
28
Otra característica que nos van a permitir los entornos de virtualización del almacena-
miento será el poder realizar un aprovisionamiento inteligente y eficiente, de esta mane-
ra, cuando creamos un disco para presentar a los sistemas (para poder utilizarlo por parte
de los servidores, aplicaciones, etc.) lo que hacemos es definir que tamaño queremos y
crearlo y ofrecérselo a esos “consumidores”.
Cuando presentamos ese disco, lo normal es que no lo ocupemos entero, por lo que nos
interesa controlar cuánto espacio realmente estamos gastando, ya que en muchas oca-
siones reservamos grandes cantidades de almacenamiento para uso futuro, aunque no lo
estemos consumiendo en el momento actual.
Esas reservas para el futuro tienen un coste muy elevado dentro de la adquisición de la
compañía por lo que una tecnología muy demandada es la de poder ofrecer esos discos
con una capacidad que realmente no tenemos por qué tener. Esto se conoce como Thin-
Provisioning.
Ejemplos de estas tecnologías pueden ser los sistemas de almacenamiento HP EVA (En-
terprise Virtual Array) que desarrolló Compaq, IBM SVC (SAN Volume Controller) o Ne-
tApp, EMC, 3PAR, etc.
Por lo tanto, si lo que buscamos es la máxima capacidad de almacenamiento, con protec-

ción, capacidad de replicación, características como Thin Provisioning, debiéremos eva-
luar a los distintos fabricantes, qué características nos ofrecen y cómo maximizar nuestra
inversión.
3.2. Virtualización de las redes

En el mundo de las comunicaciones nos encontramos con un crecimiento disparado en la
empresa respecto al número de dispositivos que conectamos y que queremos comunicar,
el inconveniente que eso nos ofrece es que necesitamos muchos puertos para conectar-
nos.
Los dispositivos de comunicación que se utilizan son los switches, un switch es un dispo-
sitivo que permite la comunicación entre varios dispositivos.
Tiene una serie de puertos, o puntos de conexión que podrán ser utilizados para conectar
a un terminal (PC, Servidor, Estación de trabajo, televisión o lo que nos interese) o bien a
otro switch para comunicarnos con más dispositivos o a otra red.
29
Existen una serie de protocolos establecidos para garantizar el correcto funcionamiento

de las comunicaciones.
Entre ellos, desde hace ya muchos años existe lo que se conoce como vLAN o LAN Vir-
tual, que es la capacidad de partir, dividir un dispositivo de tal forma que nos permita
comunicar diferentes sistemas, garantizando que solo se comunicaran entre sí los dispo-
sitivos o elementos que nosotros queramos.
Desde los comienzos de los switch, prácticamente ya está integrada dentro de sus fun-
cionalidades las tecnologías de la virtualización, con la capacidad de partirse o dividir un
mismo dispositivo.
Actualmente, el problema en las empresas viene cuando tenemos múltiples switches,

bien sea para garantizar la redundancia, y / o por qué necesitamos tantos puertos de co-
municación, en ese caso, deberíamos hacer una configuración de cada uno de ellos de tal
forma que nos garantice que la comunicación no tiene problemas.
Los problemas de comunicación podrían venir porque podríamos crear un loop o anillo
dentro de la comunicación que se está produciendo, de tal forma que un dato que se co-
munica a través de esos switches pudiera perderse dando vueltas.
Ese fenómeno complica la configuración y cableado de los dispositivos, obligando a ser

cuidadoso.
En la actualidad, existen sistemas que permiten la virtualización de la comunicación, ofre-

ciendo la posibilidad de manejar todos los dispositivos de comunicación o switches de la
empresa como si fueran un único dispositivo virtual gigante y el sistema será quien se
encargue de distribuir la información entre todos los dispositivos físicos que están por
debajo y de definir su funcionamiento real.
Esta capacidad, permite abstraernos en la gestión y evita problemas derivados de la pro-

liferación de dispositivos dentro de la empresa.
Los grandes fabricantes de dispositivos, como CISCO, HP, o más recientemente, compa-
ñías independientes como Nicira adquirida por VMware, se plantean la creación de estos
entornos de virtualización de las comunicaciones.
Existe otro punto donde se puede aplicar la virtualización dentro del mundo de las redes,
que es crear de una misma tarjeta de red múltiples, para que cada una de ellas tenga una
funcionalidad diferente, así Qlogic o HP trabajan en este tipo de tecnologías dentro de los
servidores, que permite reutilizar ancho de banda sin aprovechar y reducir el número de
dispositivos, por lo tanto, a gestionar y que deberemos alimentar dentro de los sistemas,
consiguiendo ahorros.
30
3.3. Virtualización del puesto de trabajo

La virtualización del puesto de trabajo es otra de esas tecnologías que llevan tiempo
implantadas en las compañías, aunque hasta tiempos más recientes no se ha planteado
como tal o no se ha nombrado.
Desde hace tiempo existe la posibilidad de acceder a un puesto o un dispositivo de forma

remota y que incluso varios usuarios pueden trabajar en él de forma concurrente sin mo-
lestarse ni verse.
En el momento en que comenzó la virtualización, como ya explicamos en la unidad an-

terior, lo que se pretendía era crear esa plataforma de desarrollo o pruebas de manera
independiente donde ejecutar, probar programas y desarrollar sistemas distintos.
Así surgió VMWare o Apple con sistemas que podían ejecutar Windows o de manera in-
versa, Virtual PC para hacer funcionar máquinas con distinta versión o configuración del
Sistema Operativo dentro del sistema u otras muchas variantes.
A nivel empresarial existían aplicaciones como Citrix que permitía ejecutar una aplica-
ción en el servidor y que distintos usuarios pudieran acceder de forma concurrente a ella,
garantizando que toda la información quedaba almacenaba en los sistemas centrales y sin
necesidad de que los puestos de trabajo cumplieran con todos los requisitos para ejecutar
las aplicaciones.
Citrix era la versión más extendida, pero las licencias de terminal de Microsoft también
ofrecían estas soluciones o muchas otras que pudieras pensar.
En el momento en que la virtualización ha ido explotando como tecnología en los en-

tornos empresariales, ha ido dando paso a una idea cada vez más extendida que se está
implantando en las empresas del entorno de trabajo virtual.
¿Por qué este entorno de trabajo virtual? Es un sistema que nos va a permitir que los datos
queden recluidos dentro del centro de datos de la empresa, nos va a permitir acceder des-
de distintos dispositivos, incluso de manera remota sin que los datos salgan de nuestra
central y permite que el punto de acceso sea por lo tanto móvil e independiente, facilitan-
do otra de las tendencias actuales en el mundo de los sistemas como es el BYOD (Bring
Your Own Device que permite a los usuarios utilizar su herramienta favorita para acceder
a los sistemas empresariales).
31
Para estos entornos de virtualización del puesto de trabajo existen también múltiples
versiones o variantes entre las que seleccionar aquella que más nos interese:
• Virtualización de escritorio (VDI).
• Virtualización de aplicación.
• Virtualización de la presentación.
• Virtualización del perfil.
¿En qué consiste cada una de ellas?
Aunque en esencia, todas tienen una idea común, al final tienen diferencias sustanciales
que debiéremos tener en cuenta para decidirnos por una o por otra.
32
3.3.1 Virtualización de escritorio

La virtualización de escritorio o VDI es probablemente la idea más extendida del mundo
de la virtualización para los puestos de trabajo en la empresa, lo que hace es crear una
máquina virtual completa dentro de un sistema de virtualización (VMWare, Microsoft,
Citrix…) y desde un dispositivo nosotros accederemos a nuestra máquina virtual, desde el
dispositivo de acceso tan solo necesitaremos una herramienta que nos permita ese acceso
en remoto a nuestra máquina virtual y realmente todos los datos y aplicaciones se estarán
ejecutando en ese entorno remoto.
Nos permite garantizar que la información queda almacenada en el entorno central, nos
ofrece protección de los datos y no requiere de grandes máquinas para ejecutar los siste-
mas en remoto.
Es un entorno que podremos utilizar también de tal manera que las máquinas virtuales
se creen y se destruyan después de los accesos, por ejemplo, en aulas de formación o en
entornos de alta rotación, como cyber cafes, donde la gente accede una vez y lo único que
les interesa es ese uso puntual, al terminar, la máquina se destruye y se ofrece otra.
Otra opción sería para aquellos entornos de trabajo que requieran gran capacidad de
proceso, que queremos que sigan trabajando de manera independientemente cuando no
estamos conectados, como entornos de diseño, ingeniería, o renderización para la realiza-
ción de videojuegos, películas, etc.
3.3.2 Virtualización de aplicación

La virtualización de aplicación difiere de la anterior en que ya no es toda la máquina la
que se ejecuta de manera centralizada, sino que solo algunas aplicaciones, de esta mane-
ra, cada puesto de trabajo ha de tener el sistema operativo y entorno de trabajo.
Pero si, por ejemplo, queremos acceder a la aplicación del Microsoft Word o al sistema de
ERP y es una aplicación que nosotros pagamos por usuario, lo que nos permite es que no
exista una instalación en cada cliente y gestionar por lo tanto el número de licencias de la
aplicación que tenemos en nuestra empresa.
Esto nos va a ofrecer un ahorro a la hora de adquirir licencias de software, a cambio de

garantizar nuevamente si nos interesa que todos los datos están almacenados de manera
centralizada (esto es una característica opcional).
33
Esto nos sirve para aquellos entornos donde los puestos de trabajo son generalmente au-
tónomos, pero puntualmente para ciertas aplicaciones nos interesa que estén de manera
centralizada, por protección o por gestión de costes.
Obliga a tener puestos de trabajo completos para los usuarios, cada uno el suyo, pero no
requiere instalaciones individualizadas de cada sistema.
Otro entorno donde nos permite sacar ventaja de este sistema es aquellos donde pode-
mos querer ejecutar diferentes versiones del mismo software, ya que no necesitamos te-
ner todas las versiones instaladas, estarán en el sistema central y nosotros lo que haremos
será ejecutarlas de manera remota.
3.3.3 Virtualización de la presentación

La virtualización de la presentación sería el sistema que ya se utilizaba antiguamente
como sesiones de terminal de las aplicaciones y es que para aplicaciones empresariales
que se deben de ejecutar en máquinas con una serie de requerimientos específicos, nos
puede interesar el acceder de manera remota.
En este caso, frente al primero de virtualización del escritorio difiere en que el acceso por
parte de todos los usuarios es a la misma máquina, no una específica para cada usuario,
pero sí que permite el acceso de manera concurrente a la misma aplicación (si esta lo
permite).
Nos ofrece, por lo tanto, protección de los datos, movilidad, pero en este caso acceden
todos los usuarios al mismo sistema, no a nuestra máquina en cada caso.
3.3.4 Virtualización de perfil

Es una característica más de trabajo en red, pensada para aquellos entornos donde el
usuario no tiene un puesto de trabajo concreto, sino que se mueve de uno a otro, por dis-
ponibilidad o necesidad, pero cada usuario tiene unas características, es, por lo tanto, para
aquellos sistemas con movimiento de usuario, pero con personalización de a qué pueden
y deben acceder.
Un ejemplo de dónde puede ser interesante esta tecnología es en los entornos hospitala-
rios, donde tendremos un terminal, donde cada médico o enfermera puede acceder, pero
no todos deben poder ver la misma información ni tienen las mismas necesidades.
En estos casos, lo que se hace es que dependiendo de quién sea el que accede tendrá un
aspecto (personalización del puesto de trabajo) unas aplicaciones (control de seguridad)
y unos privilegios, y permite que el número de dispositivos que tengamos dentro de la
empresa se reduzca o se encuentra cerca del usuario en todo momento, ya que muchas
veces el problema radica en la distancia entre el puesto de trabajo y el terminal propio.
34
Todas estas tecnologías para su implementación, normalmente van a requerir de una se-
rie de componentes, como son:
• Entorno de virtualización: las tecnologías de virtualización son las mismas que

para el caso de los sistemas de servidores, en este entorno cobra gran importancia
Citrix, pero también tenemos VMWare y Microsoft como en el caso de los servi-
dores como elementos importantes, y en muchos casos se plantea la posibilidad
de combinar tecnologías, como Microsoft para el entorno de servidores con su
sistema Hyper-V y Citrix Xen Desktop o Citrix Xen App para los entornos de apli-
caciones o de clientes.
• Puesto de trabajo: dependiendo de qué tecnología seleccionemos puede ser un PC

Completo, una estación de trabajo o un dispositivo ligero (Thin Client), incluso
podremos acceder hoy en día desde terminales móviles, muchos Smartphone ya
permiten estas características.
• Gestor de conexiones: dependiendo del entorno que queramos utilizar, puede va-
riar, pero es un sistema que se encarga de gestionar, por ejemplo, si queremos
destruir las máquinas, o que el usuario correcto acceda a su máquina, que las má-
quinas virtuales estén disponibles, etc.
Virtualizar, por tanto, el puesto de trabajo es una tecnología que cada vez tiene más inte-
rés para las empresas, ya que ofrece una serie de ahorros como son que mantiene la vida
útil de los terminales, ya que las nuevas necesidades de proceso se quedan en el entorno
de servidor.
Ofrece más seguridad, los datos están protegidos por las políticas de seguridad de la em-
presa y se garantiza la realización de Back-up y otras estrategias de protección.
Permite ofrecer a los usuarios de la empresa la posibilidad de elegir su dispositivo de

trabajo, llegando al punto de que esta tecnología puede ser aplicada a los dispositivos
móviles. Creando dos “perfiles” dentro del teléfono y según el uso que se le esté dando al
dispositivo, tendrá un comportamiento diferente, o si los usuarios quieren puedan traer
sistemas con diferente sistema Operativo o hardware dentro de la empresa, sin obligar a
la compañía a dar soporte a tecnologías diferentes de las ya existentes dentro de la em-
presa.
Dato importante
La virtualización del puesto de trabajo es otra de esas tecnologías que llevan tiem-
po implantadas en las compañías, aunque hasta tiempos más recientes no se ha
planteado como tal o no se ha nombrado.
35
3.4. Conclusiones
La virtualización es hoy en día una tecnología presente en todos los ámbitos de la vida, es
esa tecnología la que nos permite alejarnos del entorno físico para poder estar por encima
de él y realizar las acciones de desarrollo que nos interesen.
Dado que la virtualización es algo presente en elementos como lavadoras, neveras, teléfo-
nos móviles, coches, y evidentemente dispositivos profesionales, es interesante tener un
planteamiento y un posicionamiento frente a la virtualización que queremos en nuestra
empresa para poder proteger a la misma del mal uso de esta o para aprovechar las venta-
jas y beneficios que la virtualización nos ofrece y nos permite.
Por todo ello es importante saber y conocer de su existencia, de en qué ámbitos nos puede
influir y cómo seremos capaces de sacarle partido.
La virtualización continúa avanzando y no es ya una opción sino una obligación empre-

sarial el implementarla, además de ser la base de tendencias tecnológicas como el cloud
computing, donde nos permitirá usar todos los componentes vistos anteriormente como
un servicio contratable o facturable:
• IaaS: infraestructura como servicio, en la virtualización de servidores (Amazon,

Savvys, etc.)
• DaaS: almacenamiento como servicio (entornos de nube o entornos como Box,

Dropbox, Microsoft Skydrive, RapidShare...)
• NaaS: redes como servicio para aquellos sistemas de comunicaciones y enrutado

de las mismas. (Tiene menos aplicación comercial, pero se usa o puede usar dentro
de las empresas).
• DaaS: Desktop as a Service o puesto de trabajo como servicio, de aplicación en

entornos cerrados como cyber -centros o en entornos públicos.
En definitiva, un mundo que tanto como planteamiento interno como su visión externa
ofrece posibilidades a las que hemos de prepararnos para afrontar y ser capaces de ma-
nejar, ya que tantas posibilidades pueden ofrecernos ahorros por un lado y complejidades
por el otro.
36

En esta unidad didáctica hemos visto:
Distintas tecnologías de virtualización dentro de la infraestructura empresarial:
• Virtualización del almacenamiento con sus diferentes posibilidades y entornos
• Virtualización de las redes: entorno de particionado y agrupado de dispositivos
• Virtualización del puesto de trabajo que incluye escritorios, perfiles, presentación

y aplicación.
37
4. Green IT
“La traducción literal de Green IT es Tecnologías de la Información
Verdes. Este concepto suele estar principalmente asociado al en-
torno de la ecología y como tal se comenzó a desarrollar con la ex-
plosión de tecnología ocurrida en las empresas durante la primera
década del siglo XXI.”
4.1. Introducción al concepto Green IT

Green IT es un concepto cada vez más extendido, demandado y manejado dentro de la
creación y diseño de los sistemas empresariales.
Green TI fue definido como el uso óptimo de las tecnologías de la información y la comu-
nicación para la gestionar la sostenibilidad ambiental en las operaciones empresariales,
así como en la cadena de suministro, y todos sus productos y recursos a lo largo de su
ciclo de vida.
Como tal, si nos ceñimos a su traducción literal de Tecnologías de la Información Verdes,

suele estar principalmente asociado al entorno de la ecología y como tal se comenzó a
desarrollar en los años en que el consumo energético de los Centros de Procesamiento de
Datos de las empresas se disparaba, debido a la explosión de tecnología ocurrida en las
empresas durante la primera década del siglo XXI.
En ocasiones las empresas se acogían a este motivo para realizar nuevas inversiones, para
potenciar nuevos productos o para tratar de vender una mejor imagen.
El concepto fue ampliamente extendido cuando en el año 2007 Gartner (una consultora
afincada en Estados Unidos y especializada en el mundo tecnológico) publicó un informe
llamado: Green IT: La nueva ola de la industria.
La llegada de la crisis hizo surgir un nuevo planteamiento, la posibilidad de invertir en

tecnología como fuente de reducción de costes.
En cualquier caso y sea cual sea el motivo por el que las organizaciones deciden comenzar
a aplicar políticas “verdes”, bienvenidas sean.
38
Figura 1. Motivadores de gestión ecológica.

Fuente: Freeform Dynamics (2008).
Así, vemos que las empresas seleccionan estas políticas bien por la regulación existente,
por la imagen de la compañía, por los clientes que se lo exigen o por la presión de los
accionistas, más que por estar convencidos además de por ahorrar.
El planteamiento de que el mismo sistema actual consumía más que el anterior ofrece una
limitación, como si de coches se tratara, se va apreciando como el poder seleccionar un
coche un poco más caro pero que a la larga consuma menos, nos ofrece un ahorro seguro
dentro de la empresa.
Siguiendo con la analogía de carácter automovilístico, el ahorro del nuevo vehículo no

vendrá de un único componente, aunque sea muchas veces el que más miramos, el des-
gaste de neumático, el desgaste de componentes, etc. Son elementos que también influ-
yen en la vida útil y en el gasto total que un vehículo nos producirá.
Otros elementos a tener en cuenta es el CO2 generado, en el caso del vehículo, tenemos
mediciones para ello, e incluso normativas de uso y funcionamiento.
De la misma manera, en el caso de los centros de datos de las empresas, el conseguir aho-
rrar en consumo energético es una de las variables, pero no la única a seguir para poder
realizar una gestión eficiente de nuestras infraestructuras.
39
Existen variables que nos ayudan a medir la eficiencia de un centro de datos, como es el
PUE (Power Usage Effectiveness) o efectividad en el uso de la energía. A lo largo de la
presente unidad veremos factores que influyen o afectan al PUE, pero también veremos
como este no es el único factor dentro de las políticas energéticas de la empresa que de-
bemos de acometer.
4.2. Diseño de CPD eficientes

La medición inicial del PUE se aplica a centros de datos, que no a empresas completas y
como tal planteamos la existencia de un entorno específico para los sistemas empresaria-
les, entendiendo por sistemas empresariales los servidores, almacenamiento y dispositi-
vos de comunicación.
El PUE no entra en los sistemas que se encuentran dentro de esta habitación que veremos
en otro apartado, sino que se basaría en el diseño que hagamos de nuestra habitación de
sistemas.
Un ordenador de sobremesa de una oficina consume como mínimo unos 100 vatios de
potencia por cada hora de uso, eso hace planteamos un uso sostenido de 2.4 Kilovatios
hora al día. El carbón necesario para generar toda esa energía cada día durante un año,
son más de 320 kilos, y quemar todo ese carbón genera más de una tonelada de Co2 entre
otros desechos.
En un centro de datos donde tendremos múltiples servidores, con mayor consumo que los
de un simple ordenador de sobremesa, el consumo de estas máquinas es importante, pero
al mismo tiempo necesitaremos tener en cuenta la refrigeración de los mismos.
El PUE es por lo tanto, una medida de cuánto gastamos en mantener vivo el entorno, es la
proporción entre la electricidad consumida para hacer funcionar los sistemas y la energía
consumida total. El valor ideal sería de 1.0, es decir toda la energía consumida por el CPD
es utilizada para alimentar a las máquinas.
La realidad es que también tenemos consumos derivados de la refrigeración de los mis-

mos, dado que la electricidad se transforma en calor, las máquinas generan calor y para
el correcto funcionamiento del entorno debemos mantenerlo a una temperatura correcta.
Originalmente se plantea como temperatura de funcionamiento los centros de datos por

debajo de los 20º, ya que se consideraba que las máquinas funcionaban mejor a esas tem-
peraturas.
40
En la actualidad se ha visto que los sistemas son capaces de funcionar perfectamente a

temperaturas superiores, más cercanas a los 24º o 25º.
Lo que hay que tener en cuenta es que la distribución térmica no es uniforme, así el aire
caliente sube, el frío baja y, por lo tanto, las máquinas que situemos a menor altura estarán
más frías.
Estos factores influyen en el diseño que haremos de nuestro centro. Puede ser una única
sala o un edificio completo, y deberíamos pensar cómo hacer el diseño y distribución de
los elementos.
Así, ocupar el suelo de la instalación (el espacio más frío) para poner el cableado no siem-
pre es una buena política, ya que dificulta el flujo de aire, que normalmente por eficiencia
de las máquinas estará inyectando aire frío a través del suelo.
Una forma de optimizar es la creación de los llamados pasillos fríos y pasillos calientes
de tal manera que al realizar los sistemas un movimiento del aire de la parte frontal hacia
atrás, lo que se hace es colocar los frontales en un pasillo y las partes traseras en otros.
Optimizando así los flujos de aire.
Otras consideraciones son forzar la extracción de aire mejorando el flujo, o aprovechar

elementos como es el aire frío natural, para no consumir energía para enfriarlo, tan solo
filtrarlo antes de introducirlo dentro de las salas.
Así grandes compañías como Google o Amazon o Microsoft están creando sus centros
de datos centrales a nivel mundial en sitios fríos como en Alaska o los países nórdicos, en
zonas de corrientes de aire fría para ahorrar en la generación de ese aire frío.
Evidentemente, en una empresa más pequeña esta consideración no tiene cabida, pero sí
el buscar el emplazamiento más fresco, bien en sótanos o en zonas donde la temperatura
media sea la más reducida, para así conseguir ahorros naturales en el ciclo de vida de los
sistemas.
Existen numerosos estudios y análisis de las recomendaciones más optimas para crear
este tipo de salas y cómo conseguir optimizar al máximo nuestra inversión y conseguir
un centro lo más eficiente y ecológico posible.
41
Políticas de mejora del PUE:
1. Aumentar la temperatura promedio del CPD:
Se puede funcionar con un CPD a una temperatura media de 25º mientras que tradi-
cionalmente se suele estar diseñando para un funcionamiento de entre 19º y 21º
2. Cambiar el sistema de refrigeración a refrigeración por agua, más eficiente, aunque

es más costoso en el momento de instalación, con esa mayor eficiencia conseguire-
mos un ahorro a largo plazo.
3. Diseño del flujo del aire:
El diseño del flujo del aire ha de contemplar si existen alguno de los dos problemas
más habituales, la derivación o la recirculación:
Derivación:
Figura 2 Funcionamiento derivación..

Recirculación:
Figura 3 Funcionamiento recirculación..

42
Para evitar estos problemas deberemos hacer contención de pasillos.
• Pasillo frío, pasillo caliente, con los pasillos separados para conseguir mayor efi-
ciencia.
Figura 4. Pasillo frío-pasillo caliente.

• Contención de pasillo caliente de tal forma que aislamos el pasillo caliente extra-
yendo directamente el aire caliente del entorno y así no tenemos que calentar toda
esa zona.
Figura 5. Contención pasillo caliente.

43
• Contención de pasillo frío, lo que haremos será solo enfriar aquellas zonas donde
se coge el aire por parte de los sistemas y las máquinas tendrán solo aire frío.
Aunque es un sistema perfectamente válido, normalmente la sala puede llegar a
alcanzar temperaturas demasiado elevadas para poder trabajar por parte de las
personas posteriormente, por todo esto suele ser recomendable más la contención
del pasillo caliente que la del pasillo frío.
Figura 6. Contención pasillo frío.

• Eliminar sistemas de refrigeración, con sistemas que cojan el aire del mundo exte-
rior y con sistemas de evaporación de aire y filtrado.
• Recolocar y rediseñar el suelo del CPD, colocando las rejillas de manera eficiente,
permitiendo mayor flujo de aire, y que el aire salga solo en aquellos puntos donde
es necesaria la refrigeración, no refrigerando todo el entorno. Cosa que permitirá,
además, mejorar si en el futuro cambiamos a la circulación de líquido refrigerante
• Eliminar sistemas de refrigeración, con sistemas que cojan el aire del mundo exte-
rior y con sistemas de evaporación de aire y filtrado.
44
• Construir un CPD con techos más altos. Si construimos un edificio con el techo a
una altura de 5 metros (siendo los racks de 2 metros de altura) lo que nos quedaría
es que la temperatura media de la sala se reparte a lo largo de la altura del CPD.
De este modo, la zona caliente del CPD quedaría por encima de los servidores y
manteniendo el rack completo en la zona fría, aprovechando de esta manera las
leyes básicas de la termodinámica en el diseño del CPD.
• Colocar el cableado por encima de los servidores, evitando interferencias en el

movimiento del aire frío en las zonas más bajas y por lo tanto más frías.
• Remplazar servidores de bajo nivel por servidores con alta calificación en cuanto
a su eficiencia energética.
• Consolidación de equipo inutilizado, con racionalización de aplicaciones y virtua-

lización.
• Pintar las paredes de color claro, recomendablemente de gris que es un color más
eficiente y requiere menos luz para iluminar la sala.
• Reducir sistemas de alimentación ininterrumpida (SAI, UPS) con una redundancia

de 2 (n+1) o 2n o 3n/2 (menos sistemas, no es necesario una redundancia del 100%,
se puede estudiar una redundancia más real).
• Reemplazar UPS-SAI tradicionales por sistemas híbridos rotatorios.
• Sistemas de iluminación que permanezcan con las salas apagadas mientras no

haya nadie dentro de la sala, para no generar calor y permitir menos consumo
energético cuando entre personal a trabajar dentro del CPD.
• Colocar el CPD en una zona con un mejor índice de refrigeración, para ello se ha
de estudiar qué ciudad es más interesante, existen diversos estudios que nos per-
miten ver a nivel mundial donde es más interesante. Podemos mirar en qué país y
ciudad el banco tiene intereses y podemos ponerlo donde obtengamos más apoyo
por parte del país e instituciones públicas.
45
• Estudiaremos las zonas climáticas mundiales:
Figura 7. Mapa climático.

Fuente: Universidad de Melbourne.
• Aunque más que la temperatura, nos interesa la entalpía que es la relación entre la
temperatura y la humedad:
Figura 8. Mapa de entalpía.

Fuente: Mapa de entalpía.
46
• Estudiaremos dentro de ellas qué interesa más:
Annual
Month 1 2 3 4 5 6 7 8 9 10 11 12 Average
PUE
Scan-
danavia 1.38 1.39 1.40 1.44 1.48 1.50 1.51 1.49 1.47 1.43 1.40 1.39 1.44
(Helsinki)
Pacific NW 1.42 1.43 1.43 1.46 1.48 1.49 1.51 1.51 1.49 1.46 1.44 1.43 1.46
Chicago 1.41 1.42 1.46 1.48 1.51 1.53 1.55 1.54 1.52 1.48 1.45 1.44 1.48
Southern 1.46 1.46 1.47 1.47 1.49 1.50 1.51 1.52 1.51 1.49 1.47 1.45 1.48
CA
Mid US 1.43 1.43 1.46 1.48 1.51 1.53 1.54 1.54 1.52 1.48 1.46 1.44 1.49
SE Aus-
tralia 1.53 1.53 1.51 1.48 1.47 1.45 1.44 1.45 1.47 1.48 1.50 1.52 1.49
(Sydeney)
NY/NJ 1.44 1.43 1.46 1.48 1.51 1.53 1.55 1.54 1.53 1.49 1.46 1.44 1.49
Metro
Hong 1.48 1.50 1.52 1.53 1.55 1.55 1.56 1.56 1.55 1.53 1.51 1.50 1.49
Kong
Mumbai 1.51 1.51 1.52 1.53 1.55 1.56 1.55 1.55 1.55 1.54 1.53 1.51 1.49
Chennai, 1.51 1.53 1.55 1.56 1.56 1.57 1.55 1.55 1.55 1.54 1.54 1.53 1.53
India
Figura 9. Tabla de entalpía.

Con estas premisas elegiremos lo que más nos interese.
Dato importante
El PUE es una medida para cuatificar el gasto que supone mantener vivo el entorno,
es la proporción entre la electricidad consumida para hacer funcionar los sistemas
y la energía consumida total. El valor ideal sería de 1.0, es decir toda la energía con-
sumida por el CPD es utilizada para alimentar a las máquinas.
47
4.3. Estrategias de empresariales eficientes.

Además de lo que sería el propio centro de datos de la empresa que es uno de los compo-
nentes que más energía consumirá en la empresa, no es el único punto a tener en cuenta
dentro de la estrategia de la compañía.
Así, cada vez vemos más empresas que implantan políticas que permiten un funciona-
miento más eficiente, tratando de mejorar su impacto en la sociedad.
Realizando estrategias como tratar de minimizar o reducir los viajes y desplazamientos,

incentivando el uso de herramientas de teleconferencia que permiten a la empresa garan-
tizar u ofrecer mejor aprovechamiento de los recursos.
En la adquisición de componentes, no solo sistemas informáticos también debiéramos

tener en cuenta ese planteamiento, muchos productos de mercado ya nos indican en sus
etiquetas si los fabricantes tienen en cuenta estas políticas, por lo que conseguiremos
mejorar la eficiencia en nuestra empresa de múltiples maneras más.
Si nos centramos en los componentes informáticos de la compañía hablamos desde las

impresoras a las herramientas de gestión, por lo que igualmente podemos optar por selec-
cionar componentes que cumplan con normas energéticas como la ISO 14001 o podremos
consultar cualquier otra base de datos que nos dé información acerca del uso que hacen
los propios fabricantes de los componentes energéticos.
En el momento de adquisición también deberíamos tener en cuenta toda la vida útil de

los sistemas, cómo se comportan en adquisición (qué nos dice el fabricante), qué implica-
ciones tiene durante su vida útil (los componentes o recambios necesarios para el funcio-
namiento del sistema) y el posterior desguace y deshecho del equipo.
Durante la vida útil de los sistemas, si miramos alrededor de una oficina tipo encontrare-
mos muchos sistemas que están teniendo un comportamiento ineficiente, están mucho
tiempo encendidos, pero no están funcionando o están siendo utilizados de manera in-
eficiente.
Si planteamos que una impresora, durante mucho tiempo está encendida pero no es utili-
zada, tenemos que pensar en que el sistema tenga medidas que permitan que se apague el
sistema y arranque solo cuando sea necesario (de la forma más rápida posible), eso será lo
más interesante. De la misma forma, si ponemos por defecto que la impresión se haga en
formato que utilice ambas caras de la página o hacemos una consolidación de impresoras
dentro de la empresa, reducimos el número de sistemas que tendremos consumiendo
energía y desaprovechadas.
48
Al final, reducir el número de equipos, pasar a sistemas compartidos, eliminar las máqui-
nas individuales, realizando solo impresiones cuando el usuario está delante de la má-
quina y mientras tanto queda apagada, la máquina podrá reducir sus consumos y el estar
encendida de manera ineficiente.
Otro tipo de actitudes vitales, como tener enchufado constantemente los ordenadores
portátiles o los cargadores de teléfono cuando no están en uso genera un consumo ener-
gético.
Aprovechar sistemas como la virtualización que vimos en anteriores unidades, nos puede
servir para reducir el número de sistemas diferentes necesarios dentro de la compañía,
así como sustituir puestos de trabajo por entornos más energéticamente eficientes como
pueden ser los thin-client o dispositivos ligeros que consumen menos energía a cambio
de ejecutar máquinas virtuales de manera remota.
Para la vida posterior de las máquinas debemos tener en cuenta múltiples factores, por
ejemplo, podemos alargar la vida útil de los sistemas con la utilización de la virtualiza-
ción, utilizando aquellas máquinas ya existentes en las empresas como herramienta de
conexión para las máquinas virtuales alargando su vida y no necesitando renovar los
sistemas.
Si no sirven para ser reutilizados de una forma más eficiente para la empresa, podemos
optar por donarlos a la caridad o cualquier otra solución que permita alargar la vida del
sistema.
A la hora de desecharlos, sería importante considerar elementos como llevarlos a un pun-

to de reciclaje, donde sea separado el plástico del metal para que puedan ser reutilizados.
Por todo esto, si en el momento de adquisición de los sistemas tenemos en cuenta todos
los componentes, podremos poner en la balanza de la contratación todo el ciclo de vida
del sistema.
El uso de herramientas de video presencia puede ahorrar el número de viajes necesarios,

es cierto que en ocasiones no es posible reducirlos, pero si podemos plantear estas so-
luciones para reuniones y facilitar la toma de decisiones, nos permitirá ahorros a nivel
energético y que nuestra compañía genere menos emisiones de CO2.
Otra idea que se puede realizar es reutilizar la energía, por ejemplo, aprovechar el calor
generado por el centro de datos para recalentar la oficina en invierno u otras tecnologías
de reutilización energética.
49
En el planteamiento de usos eficientes estaría colocar sensores en los pasillos o habita-

ciones, de tal manera que no se malgaste luz si no hay personas dentro del pasillo o habi-
taciones tales como cuartos de baño o el propio centro de datos.
Para poder plantear todos estos cambios, una buena práctica sería hacer del responsable
de sistemas de la empresa (CIO) también responsable de la factura energética, en muchas
ocasiones, al no participar del pago de facturas y no tener implicación final en el ahorro
conseguido, se reduce la cantidad de energía que se desperdicia dentro de la empresa.
Poder trabajar de manera remota, permitiría ahorros energéticos en los desplazamientos

y facilitaría el trabajo de las personas.
Si establecemos todas estas políticas, el siguiente paso sería publicitarlas de tal manera
que los proveedores también tuviesen que acogerse a estas prácticas para hacer más efi-
ciente el entorno.
Realizar análisis de los dispositivos que tenemos en las oficinas de tal manera que poda-
mos detectar dispositivos que no se estén utilizando y poder quitarlos, reducir los siste-
mas con la virtualización y añadir si es posible refrigeración con aire natural y gratuito si
el clima nos lo permite.

• Cómo el Green IT puede influir en nuestras vidas de múltiples maneras y los be-
neficios y ventajas que conseguiremos siguiendo esas sencillas recomendaciones
que se ofrecen.
• Como diseñar un CPD eficiente según varias tecnologías; los motivos que nos pue-
den llevar a hacer un CPD más eficiente y el adoptar las diferentes políticas de
mejora, como optimización de la temperatura, elementos de diseño propios o la
simple selección del sitio donde colocar nuestro CPD a nivel mundial o local bus-
cando y controlando elementos como la temperatura o la entalpía.
• Cómo tomar estrategias eficientes en la empresa, que también pueden servir para
la vida diaria y que nos ayudarán a tener un entorno con menor consumo y más op-
timizado consiguiendo ahorros económicos y beneficios para el medio ambiente.
• Una política de eficiencia energética deberá de venir dictada desde la dirección y

ser acatada e implementada por todos los empleados de la compañía.
50
5. Cloud Computing
“La sociedad actual, acostumbrada a utilizar Internet, ha impulsa-
do a las empresas a tener un interfaz tipo Internet, accesible desde
un navegador. El hecho de que un programa esté restringido al ám-
bito local de la empresa pierde sentido y poner toda la información
en un interfaz web la convierte en más accesible a través de los na-
vegadores.
5.1. Introducción al concepto

Antes de comenzar tenemos que tener claro que cuando hablamos de Cloud Computing o
computación en la nube significa que vamos a tener acceso a algunos servicios a través de
la tecnología de Internet. Entendiendo por servicio aquello que a nosotros nos interese,
empezando por lo más básico del mundo de la informática como puede ser un PC (DaaS)
o un servidor con su infraestructura asociada (IaaS) hasta cualquier aplicación que noso-
tros utilizamos habitualmente (SaaS). La diferencia es que al usarlo o solicitarlo con esa
tecnología de Internet, lo haremos a través de un navegador (aunque luego el disfrute de
ese servicio pueda ser con una aplicación intermedia) y un punto muy importante es la
capacidad de hacerlo de manera elástica. ¿Qué quiere decir que lo hacemos de manera
elástica? Que podremos ir añadiendo capacidad a ese servicio a medida que lo vayamos
necesitando.
A lo largo de la evolución de la tecnología en nuestras vidas Internet ha ido llegando

de manera cada vez más natural y habitual, en multitud de ocasiones nos encontramos
utilizando tecnologías y muchas veces no nos preguntamos dónde o cómo estamos apro-
vechándolas.
La llegada de Internet nos ofrece, por lo tanto, una nueva manera de trabajar, que si bien
la podemos plantear como diferente es una evolución que se ha ido produciendo poco a
poco.
Así podemos ver como en la antigüedad intercambiábamos objetos para conseguir ali-
mentos a cambio de herramientas, posteriormente llega al mundo el uso del dinero como
herramienta que permite la adquisición de bienes, y se monta un entorno de comercio,
apareciendo tiendas donde podemos ir a comprar lo que nos interesa (“facilitándonos la
adquisición de objetos necesarios”).
51
Pero en ocasiones la tienda que nos interesaba no estaba al lado de nuestro domicilio, así
que podíamos hacer encargos por teléfono, o por catálogo, o pedir un libro a la librería que
lo encargaba al distribuidor y nos lo hacían llegar.
Parece casi lógica la aparición de tiendas de venta a través de Internet como una evolu-
ción de estas formas de comerciar.
¿Por qué seleccionar esta analogía? Bueno, una de las empresas que mejor representan la
idea de Internet es Amazon (hablaremos de ella más en profundidad) que comenzó como
una tienda encargada de vender libros a través de Internet.
Para poder ser eficiente en su venta de libros por Internet, tuvo que construir grandes cen-
tros de datos que siempre estuvieran disponibles para que su tienda no cayera y estuviera
accesible para todos los clientes, estuvieran donde estuvieran.
En ese afán por crecer y llegar a hacerlo de la mejor manera posible, llegaron a crear cen-
tros de datos tan automatizados y tan eficientes que decidieron que la capacidad sobrante
de cómputo que tenían dentro de sus centros de datos la podían revender reaprovechando
todo lo que ellos eran capaces de hacer para otras empresas.
De esta forma nace Amazon EC2 que es la nube de Amazon Elástica donde cualquier
empresa que lo desee y lo contrate podría alojar sus sistemas, o bien para desarrollo y
pruebas, o directamente operar, así hay muchas compañías actualmente muy conocidas
en el mundo de Internet de diferentes países del mundo, operan desde sus sistemas.
Otra de las evoluciones que se dio de manera natural, fue la evolución del software dentro
de Internet, primero los softwares empresariales eran grandes sistemas complejos y poco
amigables, poco a poco fueron teniendo interfaces cada vez más amigables para los clien-
tes que les permitían ser utilizados de una manera más sencilla.
En esa evolución, como la gente se acostumbraba a utilizar Internet, se paso a tener un in-
terfaz tipo Internet, accesible desde un navegador, por lo que el hecho de que ese progra-
ma estuviera restringido al ámbito local de la empresa dejaba de tener sentido al poner
toda la información en un interfaz web podría ser accesible a través de los navegadores.
Sacar la información de la empresa y que estuviera toda en Internet es, por lo tanto, un
paso casi sencillo.
Todo este conjunto de evoluciones es lo que hoy en día ha dado en llamarse Cloud Com-
puting.
52
Para conocer cómo funciona, vamos a ver los diferentes tipos de Cloud Computing que
existen, desde las dos perspectivas, el servicio que ofrecen o desde donde se oferta ese
servicio para conocer las diferentes posibilidades que tendríamos dentro de las empresas
y formar estos entornos de Cloud Computing y seleccionar cuál o cuáles serían los que
más nos interesarían en nuestro entorno.
5.2. SaaS
El SaaS o Software as a Service es aquel que nos ofrece el acceso a nuestras aplicaciones
a través de Internet y nos presenta de manera flexible el uso de las mismas.
Actualmente, todos en nuestros entornos -a nada que estemos familiarizados un poco con
las tecnologías- estamos utilizando o tenemos componentes del mundo SaaS, aunque en
muchas ocasiones no lo sabemos.
El entorno SaaS nos permite tener el uso de una aplicación a cambio de un precio. Por
ejemplo, podemos tener correo electrónico disponible en Internet con una capacidad de
almacenamiento.
Nos planteamos en ocasiones qué eso que no tiene un precio, ya que disfrutamos de él
de manera gratuita, pero lo cierto es que lo hacemos a cambio de la publicidad que los
proveedores introducen en él.
Del mismo modo, existen otros entornos de software, como aplicaciones, o tener acceso a
documentos a través de Internet, que nos ofrecen por pequeño coste de licencias.
Algunos de los sistemas más establecidos dentro de este entorno son los relacionados
con el mundo del CRM, el software de gestión de clientes o de la fuerza comercial de las
empresas requiere de disponibilidad de acceso desde cualquier punto, ya que los comer-
ciales en muchos casos no se encuentran sentados en la oficina, sino haciendo su trabajo
de visitar clientes.
Por lo tanto, el tener acceso a las aplicaciones de forma remota es un entorno interesante
y útil para los responsables de la fuerza comercial.
En multitud de ocasiones, este conjunto de usuarios varía rápidamente en número o com-

posición, por lo que el poder acceder desde Internet y no montar una infraestructura
completa asociado para ello es una ventaja que nos puede permitir controlar nuestros
gastos en un momento dado.
53
Pagaremos por el número de usuarios activos que tengamos durante un periodo dado
y eso nos da control sobre los costes, la facturación y dar de alta o baja nuevos usuarios
tiene un coste que conocemos y controlamos.
Por esto, es uno de los entornos de más crecimiento y que más están evolucionando, con
la llegada de todo tipo de aplicaciones a través de Internet mediante el pago de licencias
por uso y usuario.
5.3. PaaS
Visto que podemos tener un software igual para todos como un servicio, un problema que
nos podemos encontrar es si nosotros queremos aprovechar todas estas ventajas, pero
queremos personalizar ese entorno de software, ahí es donde surge el entorno de PaaS, o
Plattform as a Service.
Es uno de los entornos menos conocidos de utilización del Cloud Computing que nos
ofrece la posibilidad de alquilar no una licencia de software, sino una plataforma donde
ejecutar nuestro software.
Por ello, los proveedores lo que nos dan son infraestructuras dotadas de un sistema ope-
rativo que puede ser fijo o variable, un entorno de desarrollo donde ejecutar nuestras apli-
caciones y la conexión con los elementos adicionales que podamos necesitar de carácter
estándar, como una base de datos o un sistema de servicio web.
Así podríamos poner nuestra aplicación que utilice una base de datos y un sistema web
para poder acceder a ella, beneficiándonos de que los parámetros y la gestión se hacen por
parte del proveedor, y nosotros tan solo nos encargaremos de nuestra aplicación puntual.
Los casos más conocidos dentro de este entorno serían Azzure de Microsoft, que, aunque
pudiera parecer no ofrece entornos solo Windows, sino que también si lo necesitamos
podremos acceder a máquinas Linux, pero con conexión a sus bases de datos y sistemas
de publicación o desarrollo basado en .Net
También tenemos empresas como Force.com que es la plataforma tecnológica de Sales-

force.com, uno de los líderes del mundo SaaS, que ofrece su plataforma para poner ahí
nuestras aplicaciones.
Este tipo de entornos, por lo tanto, son interesantes para sistemas en desarrollo, para crea-
ciones basadas en una plataforma o para aquellos donde requiramos una aplicación con
desarrollo propio que podamos querer conectar con entornos SaaS.
54
5.4. IaaS
El siguiente nivel dentro de la pirámide sería el IaaS, que es la presentación de infraes-
tructuras como un servicio, este caso es el que se desarrolla habitualmente dentro de las
empresas, pero también está teniendo mucha importancia su utilización en Internet.
Como comentamos antes, empresas como Amazon que han creado grandes centros de
datos para ellos mismos, ofrecían la posibilidad de gestionarlos y manejar las infraestruc-
turas y que los clientes únicamente tengan que pagar por el espacio de las mismas que
estén utilizando.
Para llegar a estos entornos se basan en una tecnología vista en anteriores unidades
como es la virtualización, que nos va a permitir crear y realizar instalaciones de máquinas
de forma muy rápida, ya que tan solo son un conjunto de datos que utilizan los recursos.
A partir de ser capaces de crear nuevos servidores de forma rápida, con los parámetros
que tengamos definidos, seremos capaces de hacerlo de forma elástica cuando sea nece-
sario.
Basado en estas premisas, gran cantidad de compañías ofrecen en la actualidad la posibi-

lidad de tener máquinas dedicadas donde poner aquello que nos interese, o para probar si
los sistemas funcionan de manera rápida y fácil.
Así es una base que nos permite tener entornos de fácil crecimiento a un coste muy ase-
quible, ya que no necesitamos toda la inversión, solo el coste del alquiler de la plataforma
durante el tiempo que la necesitemos y la vayamos a utilizar.
5.5. XaaS
Cada vez más las empresas, para diferenciar el tipo de servicio que ofrecen nos hablan de
los sistemas XaaS, donde la X se puede referir a cualquier característica, empezando por
entornos de comunicaciones, almacenamiento, o uno de los más extendidos puestos de
trabajo, que denominaríamos DaaS o Desktop as a Service.
Aprovechando la posibilidad de virtualizar el puesto de trabajo de los usuarios, o simple-

mente porque nos interese tener nuestro equipo accesible desde cualquier entorno y en
cualquier momento, es posible ofrecerlo como un servicio.
Existen empresas en Internet que nos permiten tener un puesto de trabajo al que acce-
deremos desde un navegador, la propia Google trabaja en este sentido con el objeto de
aligerar los puestos de trabajo y tener toda la información en Internet.
Eso dentro del entorno empresarial, nos permitiría ahorros ya que los usuarios pueden
trabajar de forma remota y tener acceso a los datos o sistemas o aplicaciones que nosotros
definamos.
55
Asimismo, en los próximos años podremos ver la proliferación de muchos entornos como
servicio con denominación propia, aunque estos son los principales.
5.6. Cloud privado

Hasta ahora, cuando hablamos de los entornos de Cloud Computing hablamos basándo-
nos en qué los elementos están disponibles en Internet.
Pero muchas veces por el tipo de nuestra empresa, por la tipología de la información que
manejamos, o por evolucionar nuestra infraestructura ya existente, podemos pasar a ofer-
tar nosotros de manera interna a nuestra empresa los recursos informáticos disponibles.
A este tipo de entornos, donde la infraestructura funciona de manera equivalente al mun-

do basado en Internet, pero lo hacemos dentro de nuestro Firewall (no tiene por qué estar
dentro de nuestro edificio, puede ser un proveedor externo quien nos dé el servicio), pero
si lo posicionamos dentro de nuestra red pasa a ser lo que se conoce como una nube pri-
vada.
Las nubes privadas son un punto evolutivo dentro de la empresa donde podemos llegar
tras pasar por los pasos de la estandarización, gestión y automatización de nuestros sis-
temas.
Aprovechándonos de la tecnología de la virtualización, si hemos automatizado procesos,

podremos dinamizar la puesta en marcha de servicios dentro de nuestra empresa y podre-
mos tener elementos como una mayor disponibilidad y facilidad de uso.
Un beneficio asociado, es poder conocer el coste de cada sistema o servicio antes de su

puesta en marcha, de esta manera, conseguiremos ser capaces de imputar costes de los
servicios ofrecidos por el departamento de sistemas al resto de la empresa.
Generalmente, las nubes privadas se usan para entornos IaaS, pero pueden existir para
cualquier otro tipo, como Daas, ya que si virtualizamos los puestos de trabajo y todas las
necesidades asociadas a los mismos, podremos obtener que la puesta en marcha de un
nuevo puesto para cada nuevo usuario de nuestra empresa sea algo rápido, dinámico y
con un coste a imputar al departamento que lo solicite.
El poder ofertarlo, puede ser un aliciente en las empresas ya que nos ayudaría a controlar
y conocer los costes derivados de los puestos de trabajo de los usuario, además de poten-
ciar tendencias como el BYOD (Bring Your Own Device o lleva tu propio dispositivo) don-
de el departamento de sistemas solo se encarga de ofertar un PC y el usuario elige cuál es
su entorno preferido, siempre y cuando tenga la posibilidad de utilizar la aplicación por la
que se acceda al puesto de trabajo que muchas veces un simple navegador.
Por todo esto, cada vez más es una evolución dentro de los entornos empresariales.
56
5.7. Cloud público

Los ejemplos que hemos visto al principio de Amazon, Microsoft, SalesForce.com o la
propia Google, son ejemplos de empresas con grandes ofertas en los entornos del Cloud
Computing.
Generalmente, todo este tipo de ofertas están orientadas a su acceso a través de Internet,
y con sistemas que no van a estar dentro de los sistemas informáticos propios de la em-
presa.
A esto lo conocemos como Cloud público o la nube pública. Es generalmente el entorno

más conocido y el más fácilmente entendible por los consumidores, pero también acarrea
una serie de riesgos que deberemos tener presentes.
Están factores como la falta de control de los recursos, que la disponibilidad de la informa-
ción ya no es responsabilidad nuestra lo que conlleva ventajas e inconvenientes.
Cada vez hay más proveedores de soluciones cloud debido a la facilidad para ofertarla y
la sencillez de adopción por parte de los usuarios.
Nos permite tener características como acceder desde dispositivos móviles desde un na-
vegador en cualquier entorno o trabajar de manera fácil de forma remota si nos remitimos
a los entornos empresariales.
Es, por lo tanto, una tendencia que ya no es una novedad pero que todavía está en proceso
de adopción por parte de muchas compañías y que continuará avanzando.
5.8. Cloud híbrido

Son un tipo de nubes poco conocidas, las denominadas nubes hibridas, que son aquellas
donde combinamos las nubes públicas y las nubes privadas.
Es un hecho que muchos sistemas o aplicaciones son tan complejos que disponen o inter-
vienen de manera simultánea muchas aplicaciones a la vez.
Si en nuestra empresa queremos poner en marcha un servicio de estos, y lo queremos ha-

cer aprovechándonos de sistemas Cloud, podemos combinar entornos dentro de nuestra
empresa gestionados por nosotros y controlados, con elementos dinámicos en Internet
que se nutran de los datos que tenemos nosotros en local.
57
Así, un ejemplo claro para los sistemas híbridos: sería el poder tener una aplicación con
su base de datos dentro de nuestra empresa, pero el portal web de acceso por parte de los
usuarios o de los clientes en un entorno público, así ambos entornos estarían conectados,
el portal web cogería los datos de nuestros sistemas, pero si aumenta en un momento
dado la demanda por parte de los usuarios, por ejemplo en un portal de comercio elec-
trónico tras un anuncio en horario de máxima audiencia, o en una universidad en el mo-
mento de matriculación, el portal que dé soporte podrá aumentar en características o en
número de sistemas que estén ofertando el servicio, intentando dar de manera constante
el mejor servicio.
Para afrontar demandas de servicio puntuales en muchas ocasiones las empresas com-
pran máquinas, almacenamiento y sistemas más potentes de lo que necesitan.
Si pudiéramos hacer que esas demandas puntuales sean afrontadas por sistemas externos
podríamos abaratar los costes de adquisición de nuestros sistemas, y solo pagaríamos el
precio extra en el momento que fuese necesario.
Por lo tanto, los entornos híbridos son muy útiles y prácticos para nubes del tipo de in-
fraestructuras o IaaS, pero los entornos empresariales del tipo SaaS, también pueden fun-
cionar de manera híbrida.
No es exactamente lo mismo, pero si conectamos sistemas externos en nube, tipo Sales-

force en nuestro CRM o Microsoft Dynamics con los sistemas internos de personal, ERP
o de gestión de la cadena de suministros, estaríamos combinando las ventajas del mundo
público con el mundo privado.
Es, por tanto, una solución que nos puede permitir evolucionar.
Dato importante
Cuando hablamos de Cloud Computing o computación en la nube significa que

vamos a tener acceso a algunos servicios a través de la tecnología de Internet. En-
tendiendo por servicio aquello que a nosotros nos interese, empezando por lo más
básico del mundo de la informática como puede ser un PC (DaaS) o un servidor con
su infraestructura asociada (IaaS) hasta cualquier aplicación que nosotros utiliza-
mos habitualmente (SaaS).
58

Los diferentes entornos que aplican en el mundo de Cloud Computing, según su contra-
tación o alojamiento, pueden ser SaaS, PaaS, IaaS, XaaS depende de que componentes
contratemos y podrán ser públicos, privados o híbridos según donde se encuentren los
datos y las aplicaciones.
Cómo el Cloud Computing es una tendencia en continuo auge y nos puede ayudar a cam-
biar la forma de trabajar de las empresas.
59
6. Infraestructura tecnológica
“La infraestructura tecnológica es uno de los factores que puede
ayudar a definir la eficiencia de una empresa. El número de má-
quinas en los entornos empresariales llegó a un punto que hicieron
necesarias evoluciones para poder darles cabida, tecnologías que
permitieran compartir el almacenamiento entre las máquinas, com-
partir los datos, herramientas de securización del entorno y evolu-
ción en los terminales de acceso”
6.1. Historia
La evolución de la tecnología en las empresas, ha ido avanzando de manera constante,
desde los primeros tiempos de la Revolución Industrial en la que se implantaron elemen-
tos como la cadena de montaje, la creación de máquinas industriales, hasta llegar a las
primeras computadoras.
La llegada de las primeras computadoras capaces de ejecutar cálculos de manera rápida

y eficiente, que ocupaban mucho espacio, aunque según fueron creciendo en capacidad
se reducían en tamaño.
Empezó a aparecer la posibilidad de conectarse a las máquinas a través de terminales, que

poco a poco fueron creciendo en importancia hasta llegar al nivel los terminales de PC o
computadoras personales que podían funcionar de manera autónoma.
La constante reducción de los servidores y crecimiento de los puestos de trabajo, dio paso
a los entornos cliente - servidor. A partir de ese momento se llegó a la posibilidad de eje-
cutar aplicaciones complejas de manera remota en los servidores.
Las características de los servidores y de las propias aplicaciones motivan que cada vez
que necesitamos una nueva aplicación, eso implica la adquisición de un nuevo servidor
ya que requerían una serie de requisitos que implicaba la obligatoriedad de separar una
aplicación por máquina.
Esto hizo crecer de manera disparada el número de servidores dentro de las empresas,
para así facilitar las posibilidades de ejecutar cada una de las aplicaciones.
El número de máquinas en los entornos empresariales llegó a un punto que hicieron ne-
cesarias evoluciones para poder darles cabida, tecnologías que permitieran compartir el
almacenamiento entre las máquinas, compartir los datos, herramientas de securización
del entorno y evolución en los terminales de acceso.
60
6.2. Mercado de servidores

El crecimiento de los servidores y la mayor potencia de estos, hizo que aparecieran tecno-
logías que les permitieran partir la capacidad de cómputo con vistas a reaprovecharlos de
la misma manera que con la virtualización.
Pero no es este el único cambio que se encuentra en el mercado de servidores. En un prin-

cipio, las empresas que vendían sistemas, se dedicaban a la venta de las soluciones com-
pletas, esto hace que en un centro de datos nos pudiéramos encontrar gran cantidad de
sistemas diferentes, de diferentes épocas funcionando y trabajando de manera conjunta.
En esencia, un servidor es un computador, por lo tanto, tiene los mismos componentes:

procesador, memoria, disco duro, tarjeta de comunicaciones, etc.
Partiendo de esta premisa, los grandes clientes, aquellos que tenían grandes centros de
datos donde funcionaban de manera simultánea cientos de máquinas empezaron a de-
mandar cambios que no fueran simplemente tener la máquina más grande o más potente,
sino que permitieran eficiencias en su uso, y puesta en marcha.
Así viniendo del mundo de las telecomunicaciones donde ya existían chasis que permi-
tían albergar gran número de conexiones, que centralizaban la comunicación, se cablea-
ban una vez y cuando se necesitaban más líneas o puertos se iban agregando estos que
conectaban con el resto, se planteó la posibilidad de hacer un entorno análogo.
Con esta premisa aparecieron los sistemas de Blades, entornos adoptados por gran canti-
dad de grandes empresas donde en un mismo chasis o bastidor se podían poner múltiples
sistemas que compartieran dispositivos no esenciales, así el cableado, la alimentación o
la refrigeración eran componentes que poco a poco se fueron sacando de los servidores
para conseguir sistemas con igual capacidad de cálculo, que ocuparan menos espacio y
permitieran ahorros en los tiempos de instalación y funcionamiento, al reducir el número
de cables, optimizar su funcionamiento, facilitar el remplazo e incrementar la potencia de
cálculo por metro cuadrado del centro de datos.
Los servidores Blades no es la única mejora, ya que viniendo de los entornos de software
se pasó a sistemas que permitían la virtualización y así llegar a infraestructuras reutiliza-
das, con un mayor aprovechamiento.
Antes de la llegada de la virtualización se estimaba un uso efectivo de un servidor de una

media del 20% anual en entornos de mucha carga de trabajo, por lo que poder pasar a
aprovechamientos superiores, se considera un ahorro y una optimización.
Con la llegada de estos componentes, la virtualización, los sistemas de Blades y las redes,
los sistemas de servidores han continuado evolucionando hacia la externalización de los
centros de datos o el mundo cloud.
61
Por tanto, son entornos en constante avance y que dependiendo del estadio en que nos
encontremos tendremos más pasos para dar y mejorar.
6.3. El entorno de almacenamiento

El almacenamiento de datos es otro entorno que comenzó hace años a crecer de manera
independiente. Desde el momento en que diferentes máquinas requerían acceder a los
datos, el volumen de estos era cada vez mayor y se hacía imprescindible protegerlos, se
fue desarrollando un entorno que permitiera la creación de sistemas de almacenamiento.
El almacenamiento es la capacidad para guardar datos, esto ha ido evolucionando casi de

manera análoga a como han ido evolucionando las tecnologías manejadas en los hogares,
así hemos pasado por cintas de música o video, a los entornos de grabación láser y a las
unidades de memora, los datos a nivel empresarial también han ido evolucionando.
Aunque no se haya realizado al mismo ritmo o de idéntica manera, la forma fundamental

de almacenar información y manejarla de manera rápida es el disco duro. Esta toma su
nombre de su diseño, que era un disco (como el de un antiguo tocadiscos) que de manera
magnética almacenaba la información, con una cabeza lectora que buscaba la informa-
ción.
Esta arquitectura hace que los discos sean sistemas mecánicos y dan lugar a gran canti-
dad de averías dentro de los sistemas de almacenamiento, ya que estos se degradaban y
estropeaban. Aunque en ocasiones era posible repararlo, cada vez se fue tendiendo más
hacia la posibilidad de seguir trabajando, sin pérdidas de datos por ello, la información se
protegía con sistemas que permitieran el uso de muchos discos para guardar la informa-
ción de manera distribuida y que esta no estuviera en un único dispositivo.
A esto lo llamamos cabinas de almacenamiento, que tenían gran cantidad de discos, ade-
más permite que tengamos múltiples cabezas lectoras trabajando al mismo tiempo por lo
que el acceso a los datos es cada vez más rápido.
Estos sistemas de almacenamiento están conectados con los servidores, para darles acce-
so a la información por medio de diferentes tecnologías.
El problema de estos sistemas mecánicos tiene como inconveniente que tienen un límite
físico, a partir del cual ir más rápido o reducir el tamaño para conseguir ahorros energéti-
cos o de espacio pasa a ser muy complicado, por lo que se buscan cambios tecnológicos.
Para sistemas de protección de la información existen tecnologías y aproximaciones di-

ferentes según el objeto de la protección, la réplica de los datos, la copia de seguridad en
cinta, en disco o en otros formatos.
62
Para avanzar en la velocidad del almacenamiento actualmente existen en el mercado he-

rramientas como los discos de estado sólido, que nos permiten eliminar ese elemento me-
cánico que se degrada y estropea por un entorno totalmente digital, que permite reducir
problemas.
Estos discos de estado sólido que son de mayor velocidad, permiten tener un acceso a los
datos cada vez a más rápido, tienen, sin embargo, el inconveniente del precio.
La existencia de múltiples tecnologías dentro del mundo del almacenamiento hace que,
en muchas ocasiones, tengamos que optar por estrategias mixtas dependiendo del dato a
guardar o proteger por una u otra tecnología.
Por lo tanto, cada vez más, necesitaremos el planteamiento de estrategias dentro del mun-
do del almacenamiento para distribuir los datos.
6.4. Las comunicaciones

Desde hace décadas, las empresas no tienen máquinas independientes que funcionen de
manera aislada, y ya prácticamente no hay entornos donde no sea utilizado la conexión
entre las distintas máquinas para llegar a la red de redes: Internet.
Pero la comunicación no solo se circunscribe al ámbito de las comunicaciones entre las

máquinas, sino que tenemos más niveles de comunicaciones, como de las máquinas con
los dispositivos de almacenamiento.
Actualmente, cuando hablamos de comunicaciones entre máquinas, bien sean PC o ser-

vidores o incluso dispositivos móviles, nos referimos a las comunicaciones Ethernet, que
tienen una serie de protocolos y reglas de funcionamiento definidos, así podrán ser a
través de cable o de forma inalámbrica (Wifi) pero de manera que nos permitan ser lo más
rápidos y ágiles posibles.
Las redes Ethernet están actualmente presentes en todos los ámbitos, tenemos redes den-
tro de la empresa donde nos podremos conectar por cable, pero también tenemos Wifi,
acceso a Internet y conexiones de datos a través de los móviles, por lo que también debe-
ríamos proteger nuestras comunicaciones.
Para establecer las comunicaciones entre las máquinas y los entornos de almacenamien-
to, la comunicación ha de ser de manera directa y garantizada, no tanto por la seguridad,
sino porque no querremos perder ningún dato que queramos guardar o que hayamos
solicitado a nuestro dispositivo de almacenamiento.
63
Por ello, la tecnología o protocolo de comunicación entre dispositivos conocido como

TCP–IP, que es la base de Internet, no es válido para la comunicación entre los servidores
y el almacenamiento.
Existen diferentes aproximaciones, como cables directos, pero si queremos que muchos
dispositivos tengan acceso al mismo dato, necesitaremos tecnologías que nos lo permitan
por ello, existen entornos como el Fiber Channel que es un protocolo de comunicación a
través de cables de fibra óptica o el iSCSI que se basa en el aprovechamiento de los cables
y tecnologías de las redes Ethernet, pero con protocolos especiales.
El problema surge cuando el Ethernet es más barato, pero menos fiable y el Fiber Channel
demasiado caro y costoso de mantener.
Las comunicaciones cada vez son más rápidas y en ocasiones los dispositivos están in-
frautilizados, por ellos salen tecnologías mixtas que nos permiten hacer varias cosas a la
vez, pasar por el mismo cable tanto elementos Ethernet o como elementos Fiber Channel,
lo conocido como sistemas FCoE o Fiber Channel Over Ethernet que dan lugar a lo que se
conoce actualmente como infraestructuras convergentes.
Hay, por lo tanto, diferentes tecnologías y aproximaciones y según el entorno en el que

nos encontremos, deberíamos buscar cuál es la tecnología que nos interesa de acuerdo al
momento y a las evoluciones que deseemos hacer.
6.5. Estados de madurez

Si tenemos una infraestructura dispersa y fragmentada, con muchos entornos diferentes
coexistiendo dentro de nuestros sistemas, será interesante una estandarización de los
mismos para conseguir sistemas que posteriormente se puedan integrar en entornos más
eficientes como son los sistemas de Blades, que permitan la virtualización de los mismos
y llegar a gestionarlos de manera unificada.
En el momento que conseguimos integrar herramientas de gestión gracias a la estandari-

zación de los sistemas, podemos reducir los esfuerzos dedicados al mantenimiento de las
máquinas y centrarlos en conseguir entornos más eficientes.
Si hemos llegado a una infraestructura eficiente, podremos pasar a infraestructuras au-

tomatizadas y así seguir evolucionando en la gestión, control y eficiencia de nuestros
centros de datos.
Hay, por lo tanto, un largo camino que las empresas tienen que recorrer y según el tipo de
empresa del que hablemos se hallará en un nivel u otro de la evolución.
64
Tras el conocimiento de las diferentes opciones, estados de madurez tecnológica de las

empresas, se hace preciso conocerlos de forma ordenada para poder plantear un progra-
ma evolutivo en cuanto a la tecnología de infraestructuras que nos encontremos dentro
de las empresas.
6.5.1. Estado 1: compartimentado y propietario

La infraestructura tecnológica está creada en base a proyectos, con infraestructura espe-
cializada para cada uno de ellos, eso implica imposibilidad para la reutilización.
La administración de estos entornos es individualizada, ya que cada sistema es diferente

e independiente, se realizan procesos para cada uno de los sistemas que nos encontramos.
La organización del departamento de IT está basada en compartimentos tecnológicos, de

acuerdo a los conocimientos de cada uno, no permite ni facilita la movilidad ni la reusa-
bilidad de los procesos al ser entornos diferentes. Se funciona como un cost-center y no
como un departamento que ayude y apoye al negocio.
6.5.2. Estado 2: estandarizado

Las arquitecturas, herramientas y tecnologías estándares, permiten el reaprovechamiento
de conocimientos y de procesos, ayuda a una mayor optimización y a ofrecer mejoras.
Es un paso facilitado por los precios de adquisición por las guerras de precios de los fabri-
cantes y la separación por parte de los fabricantes de los diferentes componentes.
La estructura organizativa toma decisiones basadas en la tecnología y los estándares

planteados para su desarrollo.
6.5.3. Estado 3: optimización

Una vez que hemos conseguido una infraestructura estandarizada se puede avanzar al
siguiente nivel. Esto hace que muchas empresas se encuentren generalmente a caballo
entre uno y otro, dependiendo del elemento componente tecnológico del que estemos
hablando.
Utilizamos arquitecturas, tecnologías y herramientas estandarizadas con procesos de

gestión racionalizados y estandarizados, con lo que las personas implicadas son multi-
funcionales, tendremos expertos que manejan múltiples aspectos de manera simultánea.
65
6.5.4. Estado 4: automatizado y orientado al servicio

La infraestructura funciona de manera automatizada, gracias al nivel de gestión alcanzado
en el nivel anterior, se pueden agilizar procesos de gestión, mantenimiento y desarrollo.
Esta estandarización de los procesos ha dado paso a poder automatizarlos, por lo tan-
to, eliminamos la dependencia del momento y comenzamos a manejar la infraestructura
como un servicio para la empresa y no como un centro de costes.
Los niveles de servicio dentro de IT se pueden establecer por capas, donde cada nivel da
servicio al siguiente y conseguimos así una mayor eficiencia del conjunto de la infraes-
tructura.
6.5.5. Estado 5: infraestructura adaptativa

La gestión automatizada y la orientación al servicio dan paso a una infraestructura más
dinámica y que se puede adaptar al negocio, y no siendo un freno para el mismo, así el
departamento de IT pasa a ser un socio que ayuda a la innovación y una parte estratégica
dentro de las empresas.
Tendremos unas infraestructuras optimizadas, orquestadas y modulares que se adapten a

las necesidades del momento, consiguiendo la máxima eficiencia y la mayor optimización
en el consumo de recursos.
6.6. Plan de accion

Una vez vistos los diferentes estados en los que nos podemos encontrar dentro de nuestra
empresa, lo primero será identificar aquel en que nos encontramos.
Existen numerosas herramientas o consultoras que nos pueden ayudar a descubrir el es-
tado en que estamos. Puede que nuestra empresa no esté en un estado definido, sino que
dependiendo de si nos referimos a la arquitectura, a la tecnología, a las herramientas de
gestión o a los procesos que utilicemos en nuestro departamento nos situemos en un
nivel o en otro.
Una vez reconocido el nivel al que se encuentran las distintas áreas de nuestra empresa,
deberemos plantearnos un objetivo asequible y abordable de evolución empresarial.
66
Según múltiples estudios, en la actualidad salvo grandes empresas multinacionales y al-

gunos sistemas gubernamentales, lo normal es encontrarnos a medio camino entre un
nivel 2 o 3, en algunos casos, en empresas con un fuerte anclaje en tecnologías propieta-
rias por las circunstancias que sean, se pueden encontrar en el 1, también es posible que
empresas jóvenes, que hayan surgido en los últimos años, y aquellas que son referente en
su sector puedan estar más avanzadas.
En cualquier caso, si queremos avanzar para ayudar a que el departamento de IT sea ese
departamento que ayuda y tira en la innovación empresarial, deberíamos encontrarnos en
el estado más avanzado posible.
No existe una solución o camino único ya que, dependiendo de nuestra empresa, podre-
mos optar por encaminarnos hacia una infraestructura gestionada de manera interna o la
externalización de la misma (que muchas veces nos ayuda al planteamiento de los proce-
sos que se tienen y la optimización de las infraestructuras).
Las necesidades que debemos identificar o corregir en un CPD serían las relacionadas
con la eficiencia (mejorar la productividad reduciendo el coste) con la seguridad (seguri-
dad en la continuidad de negocio, ayudando a mitigar los distintos riesgos) y con la agili-
dad (que nos permite responder rápidamente a las necesidades de los usuarios).
Para todo esto sería interesante contar con el apoyo suficiente dentro de la organización
para poder establecer las políticas de gobierno que se quieran aplicar a partir de la iden-
tificación de los distintos campos de mejora.
Hemos visto como hay multitud de tecnologías de servidores, almacenamiento y comuni-

caciones; luego deberíamos plantear los sistemas que van a funcionar por encima, siste-
mas de virtualización, sistemas operativos, aplicaciones y distintas infraestructuras. Por
todo esto, el realizar un plan y un diseño de nuestro gobierno de IT es importante.
Dato importante
Las comunicaciones cada vez son más rápidas y en ocasiones los dispositivos están
infrautilizados, por ellos salen tecnologías mixtas que nos permiten hacer varias
cosas a la vez. Hay, por lo tanto, diferentes tecnologías y aproximaciones y según el
entorno en el que nos encontremos, deberemos buscar cuál es la tecnología que nos
interesa de acuerdo al momento y a las evoluciones que deseemos hacer.
67

• Los diferentes elementos que pueden participar en la arquitectura empresarial:
• Servidores, con sus distintas tecnologías como los servidores Blades o la virtuali-
zación.
• Tecnologías de almacenamiento masivo para guardar los datos.
• Herramientas de comunicación y las diferentes tecnologías, como Ethernet o Fi-

ber-Channel.
Los niveles de madurez tecnológica como:
• Compartimentado y particionado.
• Estandarizado.
• Optimización.
• Automatizado y orientado a servicio.
• Empresa adaptativa.
68
7. Arquitectura empresarial
“En el diseño de la arquitectura empresarial iremos bajando tan en
profundidad como sea necesario para ir especificando los diferen-
tes procesos que lo componen y alcanzar el nivel donde podamos
identificar los problemas que se puedan encontrar en la integración
de cada proceso.”
7.1. Introducción al concepto

A lo largo de las unidades hemos ido viendo cómo el desarrollo tecnológico de las empre-
sas puede haber influido en su estado actual, así, el desarrollo puntual, basado en proyec-
tos llevados a cabo dentro de muchas compañías ha dado un entorno donde las tecnolo-
gías y arquitecturas de las empresas son totalmente heterogéneas y diversas.
Esto proviene de la ventaja de llevar a cabo de manera rápida y puntual soluciones para
cada una de las necesidades tecnológicas que se tenían dentro de la empresa.
Esta situación no es algo nuevo en el mundo de la arquitectura de edificios. En ocasiones,

se dan estos casos llegando a circunstancias como la de la mansión Winchester, situada
en California, cerca de San Francisco. Allí, se compró un terreno donde se empezó a cons-
truir una casa en el año 1884 y se terminó más de treinta años después.
Durante ese tiempo, en vez de seleccionarse unos planos y un plan de obra, cada día se
hacían reuniones con el contratista y se decidía cuál sería el plan de obra para ese día, sin
ningún plan previo.
Se mantuvieron numerosos carpinteros, llegando a construir una casa con tres ascenso-
res, cuarenta y siete chimeneas y una estructura tan compleja que numerosos recuentos
coinciden en que había alrededor de ciento sesenta habitaciones, escaleras que no lleva-
ban a ningún sitio o puertas que daban a paredes selladas.
Esta arquitectura tan alocada servía para los propósitos para los que había sido construi-
da y es que según su dueña la idea era que los espíritus de todas las personas muertas a
manos de los famosos rifles creados por la familia no pudieran encontrarla y se perdieran
dentro de la casa. Hoy en día, la casa es un museo que se puede recorrer, pero advierten
que no hacerlo en solitario, pues es muy fácil perderse en ella.
69
Esta construcción alocada es el resultado por la falta de un plan de obra, unos planos que
dieran una idea clara del diseño y que ayudaran a cada uno de los participantes en el pro-
yecto a llevar un camino único.
Las ideas del diseño estaban en poder de una persona, que además los cambiaba constan-
temente, decidiendo en cada momento qué era lo que deseaba hacer para cumplir con sus
inmediatos propósitos.
De idéntica manera, las compañías deben de tener una idea, un plan que les permitan
ejecutar proyectos año tras año, de tal manera que durante periodos de tiempo sostenidos
se puedan mantener las ideas de desarrollo dentro de la compañía.
De esta manera, la arquitectura empresarial será la organización lógica de los procesos de

negocio y de las infraestructuras de IT reflejando el modelo operativo de la compañía, así
como los requerimientos de estandarización y la integración de los mismos.
Muchas empresas abordan la creación de su arquitectura empresarial con cantidad de

dibujos y análisis de los modelos existentes y los esperados para sus sistemas. Pero un
análisis masivo muchas veces no centra el foco en los recursos que son necesarios.
La clave para generar un modelo empresarial efectivo es identificar los procesos, datos,
tecnologías y elementos necesarios para interoperar con los clientes que permitan llevar
el modelo desde ser una visión a la realidad.
Los diferentes niveles de arquitectura tecnológica dentro de las empresas como defini-
mos en la primera unidad serían:
• Arquitectura empresarial o de procesos de negocio: la que nos permite definir la

estrategia a plantear desde el nivel de la organización, los negocios y los procesos
claves, así como la gobernabilidad de los mismos.
• Arquitectura de datos: define la estructura lógica y física de la gestión de los datos

dentro de la empresa, así como los recursos utilizados para gestionar la informa-
ción, ya que la información es uno de los recursos capitales de las empresas actua-
les.
• Arquitectura de aplicaciones: nos permite definir un plan de funcionamiento den-

tro de las empresas, definiendo el despliegue, funcionalidades, interacciones y pro-
cesos de las diferentes aplicaciones para gestionar su ciclo de vida.
• Arquitectura tecnológica: identificará las diferentes capacidades de hardware y

software necesarias para realizar el despliegue de las aplicaciones y sistemas de
datos, así como los procesos definidos en la arquitectura empresarial. Esto incluye
la parte de infraestructuras, redes, comunicaciones, políticas, normas, etc.
70
Ya hemos visto los diferentes niveles tecnológicos y en otras asignaturas se tratarán las
aplicaciones que funcionarán dentro de la empresa.
Una arquitectura empresarial contendrá el conjunto de modelos o descripciones necesa-

rias y relevantes para describir una empresa de tal manera que puedan ser producidos
para los requisitos de la gestión y puedan ser mantenidos durante un periodo de tiempo.
Por lo tanto, una arquitectura empresarial provee una visión común de los recursos prin-
cipales de cualquier empresa (personas, procesos y tecnologías) y cómo se deben de inte-
grar para aportar los motores de la empresa (la estrategia).
Podemos afirmar que la arquitectura empresarial tiene dos usos:
• Como una herramienta para ingeniería. En este sentido, la arquitectura empresa-

rial define unas guías de la información requerida y las metodologías empresa-
riales complementarias. Una metodología define los pasos que las diferentes per-
sonas en una compañía deben seguir para generar la información y completar la
arquitectura.
• Como una herramienta de gestión. Tras la fase de ingeniería, un gestor puede vi-
sualizar las relaciones entre cualquier componente en diferentes niveles de acuer-
do a la arquitectura. (relaciones entre procesos, recursos, información, estrategia,
sistemas de información, etc.) Con este propósito es necesario previamente haber
definido las relaciones entre las diferentes arquitecturas y los componentes conte-
nidos en esta.
Algunos de los beneficios de tener una arquitectura empresarial son:
• Documentación legible y disponible de la empresa.
• Posibilidad de unificar e integrar procesos de negocio a través de la empresa.
• Posibilidad de unificar e integrar datos a través de la empresa y conectar con pro-

veedores o clientes externos.
• Incrementar la agilidad para cambios corporativos.
• Maximizar la reutilización de los modelos empresariales.
• Conseguir una visión común del negocio y de IT.
La arquitectura empresarial está compuesta por otras arquitecturas, así una arquitectura
de procesos de negocio y una arquitectura de IT son dos piezas del conjunto de arquitec-
turas que componen la arquitectura empresarial, y esta puede ser utilizada para detectar
problemas de integración.
71
7.2. Niveles de granularidad vs. Niveles de abstracción

Cuando trabajamos con las arquitecturas empresariales debemos distinguir claramente
entre los niveles de granularidad y los niveles de abstracción.
Los niveles de abstracción serían los diferentes niveles en los que un sistema puede ser
concebido. De esta manera, un manager de procesos de negocio puede ver la compañía
como un conjunto de procesos que generan y consumen diferentes flujos que son llevados
a cabo por los recursos.
Por otro lado, un manager de IT verá la compañía como un conjunto de sistemas de in-
formación que trabajan para alcanzar objetivos diferentes. Por lo tanto, según el puesto y
departamento tendremos una visión diferente.
Generalmente consideramos que la “gente de negocio” tiene una visión más “elevada”
que la “gente de TI” porque la gente de negocio, gracias a la información que manejan,
tienen una idea más clara de cómo las diferentes piezas deben encajar en la estrategia
corporativa.
Si la arquitectura de un edificio es realizada en forma de planos, la arquitectura empresa-

rial suele estar presentada como principios, políticas y elecciones tecnológicas. Sin em-
bargo, el concepto puede ser tan vago que lo haga inabarcable.
Por otro lado, tenemos los niveles de granularidad dentro del diseño de la compañía. De
tal manera que seamos capaces de analizar cada proceso con diferente nivel de detalle,
según la granularidad que estemos observando en ese momento.
En el diseño de la arquitectura empresarial iremos bajando tan en profundidad como sea

necesario para ir especificando los diferentes procesos que lo componen y alcanzar el ni-
vel donde podamos identificar los problemas que se puedan encontrar en la integración
de cada proceso.
Por esto, crear un diagrama, una imagen que lo representa, puede ayudar a los gestores a
hacerlo comprensible y puede indicar cómo llevarlo a cabo. Esta imagen debe de ser una
vista de alto nivel de los procesos, los datos y las tecnologías deseadas, que constituyan
la base para la ejecución.
El diseño será un punto de partida para los responsables para desarrollar y crear la arqui-
tectura empresarial, aunque todas las implicaciones y requerimientos estructurales, no
suelen aparecer representados, por lo que se han de desarrollar de acuerdo a la arquitec-
tura empresarial.
Cada compañía realizará una aproximación diferente a la hora de desarrollar este diseño,
pero todas han de resaltar los componentes claves de la ejecución.
72
En esta ejecución existirán cuatro elementos en los diferentes diagramas:
• Procesos principales del negocio: este pequeño conjunto de procesos empresa-

riales que definen el conjunto de habilidades necesarias en la compañía para reali-
zar su modelo operativo y dar respuesta a las necesidades del mercado.
• Datos compartidos por los procesos principales: estos datos pueden ser los ar-
chivos de clientes que son compartidos por las diferentes líneas de producto de
una empresa o las diferentes unidades de negocio.
• Tecnologías conectoras y de automatización claves: son las tecnologías que in-

cluyen el software conocido como “middleware” que permitirán la integración de
las aplicaciones y acceder a los datos compartidos, así como a los grandes softwares
empresariales como los ERP. Las tecnologías también ofrecen portales de acceso
entre los datos y los sistemas y son las que permiten a una compañía diferenciarse
de sus competidores. Las herramientas electrónicas de acceso para los empleados,
clientes, partners y proveedores, también deberán aparecer en este diagrama.
• Clientes clave: será el cliente o conjuntos de clientes (canales, segmentos…) que

sirven de base para la ejecución de los procesos.
Estos elementos serán específicos para el modelo operativo de la compañía. Aunque so-
lemos ver similitudes entre los diagramas de compañías que sigan el mismo modelo ope-
rativo.
Existen cuatro tipos de modelos operativos: modelo de unificación, modelo de diversifi-

cación, modelo de coordinación y modelo de replicación. A continuación, describiremos
cada uno de los modelos y sus características.
7.3. Modelo de unificación

En un modelo operativo de unificación, tanto los procesos de estandarización como de
integración son necesarios para cumplir con diferentes tipos de clientes. La tecnología es
utilizada para conectar y para enlazar procesos.
A la hora de crear el diagrama principal de una compañía con un modelo de unificación

serán necesarios tres elementos. Comenzar por identificar a los clientes clave de la com-
pañía. A continuación, listar los procesos claves que deben de estandarizarse e integrarse.
Para a continuación, identificar los datos compartidos necesarios para mejorar la integra-
ción de procesos y servir a los clientes. Finalmente, si las hay, las tecnologías que permi-
ten automatizar o conectar procesos puede aparecer también.
73
Figura 1. Modelo de unificación.

Fuente: MIT Sloan Center for Information System Research.
El diseño debe reflejar una compañía altamente estandarizada e integrada con procesos
de acceso a los datos de forma estándar para conseguir que los productos y servicios
estén disponibles para los clientes. En el diagrama pueden aparecer o no las tecnologías
clave, dependiendo de lo importantes que sean para la visión particular de la dirección.
7.4. Modelo de diversificación

El modelo operativo de diversificación es el modelo contrario al de unificación, contiene
baja estandarización y baja integración. Cada negocio es ejecutado de forma más o menos
independiente, aunque pueden existir oportunidades para compartir servicios a través de
la compañía.
Un modelo extremo del modelo de diversificación sería la ausencia total de una arquitec-
tura empresarial. Una empresa que quiera tener sinergias entre sus distintos negocios.
Sin embargo, más frecuentemente las compañías optan por un modelo de diversificación
que permite economías de escala a través de una tecnología compartida.
Estas tecnologías compartidas serán, por lo tanto, los elementos clave del diagrama del
modelo. Tecnologías y servicios compartidos en ocasiones incluyen centros de datos, re-
des de comunicaciones, centrales de compra y help desks.
74
Cuando diseñamos un modelo de diversificación, comenzamos con las tecnologías que

pueden ser compartidas para aportar economías de escala, estandarización o cualquier
otro tipo de beneficios.
Incorporaremos los restantes elementos, tipos de clientes claves, modelos de negocio y

datos, solo cuando sean necesarios para el modelo operativo. Por ejemplo, algunas com-
pañías requieren procesos estandarizados y datos para informes, gestión de riesgos, o
cualquier otro caso que se dé.
7.5. Modelo de coordinación

El modelo de coordinación ofrece servicios integrados para cada conjunto de clientes
clave. La integración resulta de compartir datos entre las diferentes unidades de negocio
para ofrecer un interfaz común para los clientes. Debido al amplio catálogo de productos
diferentes que se pueden llegar a ofrecer, las compañías pueden optar por la integración
de los procesos o los productos sin llegar a la estandarización.
Figura 2. Modelo de diversificación.

75
El diagrama de un modelo de coordinación incorpora un énfasis en la integración y a

partir de ahí hace foco en la compartición de datos. A menudo el diagrama también resal-
tará tecnologías importantes que nos indicarán como los distintos elementos accederán
a los datos. Debido a que muchos procesos en un modelo de coordinación son únicos, es
menos importante mostrarlos en el diagrama. Sin embargo, puede ser útil mostrarlos al
menos algunos de los procesos que deberán de ser coordinados.
Cuando diseñamos el modelo de coordinación, deberíamos comenzar con los clientes

claves (por ejemplo, sectores o canales) que serán compartidos a lo largo de las unidades
de negocio. Después identificaremos los conjuntos de datos de la compañía que serán
compartidos para servir a los clientes.
A continuación, identificaremos cualquier tecnología que sea clave en la integración de

datos. No es esencial reflejar la tecnología, pero suele ser útil para el negocio y los gesto-
res de IT para entender la clave de la integración.
Finalmente habrá que considerar si incluir los elementos de los procesos de negocio.
Figura 3. Modelo de coordinación.

76
7.6. Modelo de replicación

El modelo de arquitectura de replicación es exitoso cuando los procesos clave son estan-
darizados a través de la compañía y soportados por tecnología de automatización. Este
modelo permite una rápida expansión y escalabilidad del negocio.
El modelo de replicación gira alrededor de los procesos estandarizados. Así, el diagrama

de arquitectura empresarial mostrará los procesos estándares y en la mayoría de casos
las tecnologías claves que permiten esos procesos. Los datos rara vez aparecen en el dia-
grama porque las compañías que utilizan ese modelo, normalmente no comparten datos
entre las diferentes unidades de negocio.
Para mejorar las economías de replicación, estas compañías automatizan sus procesos
claves, a menudo creando módulos de negocio reutilizables (mostrados como modelos de
negocio encapsulados por la tecnología en el diagrama).
El diagrama de arquitectura empresarial también nos muestra normalmente tecnologías

compartidas a través de los procesos estandarizados.
Figura 4. Modelo de replicación.

77
Cuando diseñamos un diagrama de un modelo de replicación, comenzaremos por los pro-

cesos claves que serán estandarizados y replicados por las diferentes unidades de nego-
cio. A continuación, identificaremos las tecnologías que automatizarán dichos procesos.
Después consideraremos cuáles serán las tecnologías que permiten conectar las diferen-
tes unidades de negocio si las hay. Normalmente no es necesario compartir datos o iden-
tificar a los usuarios clave. En cambio, cada unidad de negocio tomará esas decisiones de
manera local.
7.7. ¿Quién debe realizar el diseño de la arquitectura empresarial?

En muchas empresas, el diseño de la arquitectura empresarial es responsabilidad de un
pequeño grupo del departamento de IT que suelen acabar secuestrados en una habita-
ción durante meses de la que solo podrán escapar después de haber generado multitud
de diagramas.
Estos diagramas generalmente parten de los sistemas ya existentes. Esto suele pasar y
se justifica porque se plantea que desarrollar la arquitectura partiendo de la ya existente
actualmente reducirá la complejidad del proyecto en el entorno de sistemas.
La mayoría de estos ejercicios acaban siendo abandonados en una estantería. Esto sucede
porque un diseño demasiado detallado acaba dando una imagen de complejidad sobre el
que raras veces se acaba abordando.
En vez de eso, la arquitectura empresarial debería empezar con un directivo debatiendo el

modelo operativo, a partir de ahí seguir el desarrollo. El modelo operativo nos permitirá
tener un diagrama a partir del cual comenzar a diseñar un punto de partida para abordar
el cambio.
En el proceso de rellenar el diagrama, la dirección es quien debe decidir qué es clave y

que no dentro de la compañía. Una vez que los elementos principales están colocados
podremos continuar con la evolución de la arquitectura.
Los modelos de arquitectura empresarial no solo sirven para rediseñar e implementar las
capacidades técnicas de la compañía, en ocasiones, las personas deben reaprender los
procesos. Así, el modelo de arquitectura empresarial y el diseño que realicemos permiti-
rán a la dirección tomar decisiones.
Cuando IT lidera el proceso de creación, puede ser llevado a cabo siempre y cuando la
persona que lidere entre dentro del proceso con IT a la hora de hacer esta nueva arquitec-
tura y diseñar y establecer el modelo.
78
Se ha observado que algunos equipos de gestión pueden desarrollar y compartir una idea
clara de lo que se quiere hacer sin realizar un diagrama. Pero en otros muchos equipos
se ha visto que tener un diagrama puede ser una herramienta útil para crear un modelo
comprensible de cómo la compañía debe de funcionar y compartir esta visión con el resto
de la organización.
Preparando un diagrama de arquitectura empresarial de manera concienzuda la dirección

puede indicar a IT y a los procesos de negocio que la involucren en una posición de ven-
taja para su ejecución e implantación dentro de la compañía.
El proceso de creación es un viaje complejo, que muchas compañías aprenden desde el

principio como conseguir valor de él.

• Los niveles de granularidad en los que podemos dividir una empresa y como ello
contrasta con los niveles de abstracción.
• El Modelo de unificación.
• El Modelo de diversificación.
• El Modelo de coordinación.
• El Modelo de replicación.
• ¿Quién debe realizar el diseño de la Arquitectura empresarial? Como siempre ve-

remos, será desde la dirección asociado a los entornos técnicos.
Dato importante
Los niveles de abstracción serían los diferentes niveles en los que un sistema puede
ser concebido. De esta manera, un manager de procesos de negocio puede ver la
compañía como un conjunto de procesos que generan y consumen diferentes flujos
que son llevados a cabo por los recursos.
79
8. SOA
“Una arquitectura orientada a servicios es esencialmente una co-
lección de servicios. Estos servicios se comunican entre sí. La comu-
nicación puede implicar el simple paso de datos o podría implicar
dos o más servicios coordinando alguna actividad.”
8.1. Introducción al concepto SOA

La integración de las distintas herramientas de la compañía, conlleva la definición clara
de los servicios para dar soporte a las aplicaciones entre si, brindando una forma clara de
hacerlo.
SOA o la Arquitectura Orientada a Servicios nos va a permitir la creación de sistemas de

información que se aproximen a los criterios de la empresa:
La arquitectura orientada a servicios de cliente (en inglés Service Oriented Architecture),

es un concepto de arquitectura de software que define la utilización de servicios para dar
soporte a los requisitos del negocio.
Permite la creación de sistemas de información altamente escalables que reflejan el nego-

cio de la organización, a su vez brinda una forma bien definida de exposición e invocación
de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la inte-
racción entre diferentes sistemas propios o de terceros.
SOA define las siguientes capas de software:
Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o tecnología,

geográficamente dispersos y bajo cualquier figura de propiedad.
De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativa son

expuestas en forma de servicios (generalmente como servicios web).
De integración de servicios - Facilitan el intercambio de datos entre elementos de la

capa aplicativa orientada a procesos empresariales internos o en colaboración.
80
De composición de procesos - Que define el proceso en términos del negocio y sus nece-
sidades, y que varía en función del negocio.
De entrega - donde los servicios son desplegados a los usuarios finales.
SOA proporciona una metodología y un marco de trabajo para documentar las capacida-
des de negocio y puede dar soporte a las actividades de integración y consolidación.
Por lo tanto, si tenemos generada una arquitectura SOA, lo que nos plantea es la posibi-
lidad de facilitar la integración entre las distintas aplicaciones para conseguir maximizar
el beneficio obtenido con nuestra infraestructura.
8.2. Servicios
Hoy en día, el mundo que nos rodea está basado en servicios como nunca antes lo había
estado. Cada persona que realiza una o varias tareas de apoyo a otras personas está reali-
zando un servicio.
De igual manera, un conjunto de personas que realizan una tarea para que otras personas
puedan acometer las suyas, están realizando un servicio de soporte.
De manera equivalente, una compañía puede llevar a cabo una serie de tareas necesarias
para su negocio o para su propósito empresarial, estará realizando un servicio.
Para poder llegar a la evolución completa, se requiere de un diseño estructurado que per-
mita a pequeños servicios, ofertados por individuos, coordinarse para ofrecer un servicio
conjunto y de mayor envergadura.
Así, en un trabajo de manufactura, muchas veces no interviene una única persona, sino
que por ejemplo si hablamos de una silla de madera, entrará quien tale el árbol, quien
extraiga la madera, quien la corte para prepararla, quien realice el encolado y quien la
barnice. Todos ellos están realizando un servicio, pero al hacerlo de forma conjunta nos
ofrecen un servicio mayor o más completo, como será la fabricación de una silla.
Para que todos estos pasos o servicios puedan dar lugar a un servicio o producto final se
requiere de ese diseño estructurado en el que cada uno sabe qué tarea ha de realizar y que
parámetros de salida son necesarios y validos.
Por lo tanto, el diseño de esa arquitectura orientada a servicios es uno de los elementos
principales en cualquier estructura orientada a servicios.
81
8.3. Arquitectura SOA

La computación orientada a servicios representa una nueva generación de sistemas que
utilizan una plataforma de desarrollo que involucra múltiples componentes, pero que tie-
ne sus propios elementos de diseño, con patrones de lenguajes, diseños de arquitectura,
conceptos, tecnologías y entornos de relación de los sistemas.
Con estas definiciones, lo que vemos es que SOA parece un paraguas muy amplio bajo
lo que podemos meter muchas cosas y la realidad es que es así, la arquitectura o los en-
tornos orientados a servicios están construidos sobre las antiguas plataformas de com-
putación distribuida, pero le añade una serie de nuevas capas de diseño, consideraciones
a nivel de gobierno de los sistemas y un amplio conjunto de técnicas y tecnologías para
implementarlo.
SOA o arquitectura orientada a servicios establece un modelo de arquitectura que ayuda

a mejorar la eficiencia, efectividad y productividad de una empresa, posicionando los ser-
vicios como lo primero que debemos de tener en cuenta cuando queremos presentar una
lógica de solución de un problema, o para la consecución de los objetivos estratégicos de
la compañía, asociado a la programación orientada a servicios.
Dentro de esta arquitectura por lo tanto podemos decir que SOA estará formada por la
combinación de tecnologías, productos, API’s (Interfaces relacionales de aplicaciones)
extensiones de la tecnología de soporte y otras partes varias.
Esta definición que nos incluye tantos y tan diferentes componentes, hace que cada apli-
cación de SOA en una compañía sea única ya que involucra todos los componentes de la
empresa y sus elementos internos.
Sin embargo, muchas veces el SOA viene asociado a la introducción de nuevas herra-
mientas o tecnologías dentro de la empresa que den soporte a la creación, ejecución, y
evolución de las soluciones dentro de la misma.
Por lo tanto, una solución orientada a servicios dentro de una empresa dará como re-
sultado una arquitectura orientada a servicios, basándose e unos principios de diseño
orientado al servicio.
Los servicios serán, por tanto, software que van a funcionar dentro de la empresa de ma-
nera independiente, y cuando nosotros queremos establecer una arquitectura que nos
permita intercomunicar los diferentes servicios, para el intercambio de información entre
los mismos, deberíamos definir que el diseño de cada uno de esos servicios o software
esté realizado de tal manera que sea capaz de comunicarse o conectarse con otros.
82
Por este motivo, cuando hablamos de SOA, nos estaremos refiriendo a entornos de desa-
rrollo que no son en sí elementos concretos de la estructura, del lenguaje utilizado ni de
la aplicación deseada, sino de la forma de diseñar y desarrollar aplicaciones, software o
servicios para poder interrelacionarlos entre sí.
Cada servicio tendrá su propio conjunto de capacidades de acuerdo al entorno donde se

encuentre. Estas capacidades serán susceptibles de ser invocadas desde fuera (por otros
servicios) para lo que se deberán de publicitar de manera expresa la manera de invocar
estas capacidades, esto se puede hacer de manera equivalente a lo que sería una API.
8.4. Beneficios de SOA

El SOA hace un especial hincapié en la reutilización de sus componentes, la idea que te-
nemos detrás de estas arquitecturas o tecnologías orientadas a servicios es que podamos
reaprovechar los desarrollos de servicios que se realizan en un momento dado para la
creación de otros servicios y por tanto tener mayores servicios.
De esta manera, si queremos reutilizar correctamente los diferentes módulos, crearemos

un catálogo de servicios que tendrán un gran porcentaje de capacidades y de servicios
libres de dependencias que podremos reutilizar de un proyecto para otro.
Esto nos ofrece claramente ventajas en cuanto al tiempo necesario para el desarrollo de
nuevos servicios y el tiempo de puesta en marcha y de utilización de los mismos.
Sin embargo, para poder generar este catálogo, los servicios que creamos o desarrollamos
deben seguir una serie de premisas, o estar desarrollado de una forma tal que seamos
capaces de identificar quién y cómo podrá acceder a los mismos, para que así nuestro
catálogo sea comprensible y reutilizable.
La consecuencia por lo tanto es que nos tendemos a alejarnos de las infraestructuras

basadas en silos, en entornos únicos que funcionaban de manera completamente inde-
pendiente y nos movemos a los sistemas que están formados por la suma de múltiples
servicios que dan como resultado un servicio final que nos permita dar respuesta a las
necesidades de la empresa en cuestión.
Así, cada vez seremos capaces de crear más y más sistemas, no por el desarrollo de los
mismos, sino por la combinación de servicios prexistentes que darán como resultado un
nuevo conjunto de servicios.
83
A medida que crezcamos sobre este método de creación e implantación de sistemas, los
anteriores conceptos basados en aplicaciones y en entornos de silos que funcionan de
manera independiente irán poco a poco desapareciendo para dar paso a arquitecturas
basadas en servicios.
Las aplicaciones en los entornos de SOA carecen de sentido individual, ya que o bien es
un conjunto de servicios, o bien es en sí mismo un servicio para otro sistema mayor.
Por tanto, el concepto de aplicación como tal no desaparece, sino que pasaremos a tratarlo
no tanto como una aplicación tradicional, sino como un servicio que alimenta a un proce-
so para que al final seamos capaces de llevar a cabo nuestro objetivo, que es el desarrollo
de la empresa.
Una vez que veamos que las diferentes aplicaciones o servicios dejan de funcionar de
manera independiente, hemos de tener en consideración la integración de los diferentes
servicios dentro de la estructura.
Los diferentes servicios se han desarrollado de acuerdo a un patrón prestablecido para

poder acometer su utilización y su posterior reutilización, por lo que lo servicios pasan a
tener importancia dentro de la integración de los mismos si queremos poder reutilizarlos.
En el pasado, la integración entre diferentes aplicaciones implicaba muchas veces la in-

terconexión de sistemas que en muchas ocasiones eran incompatibles, por que pudieran
estar basados en diferentes tecnologías, plataformas o lenguajes.
También podía suceder que simplemente no estaban pensados para conectar con nada
fuera de sus propios elementos internos y no estaban, por lo tanto, diseñados para in-
terconectar con otras aplicaciones. La necesidad cada vez mayor de conectar diferentes
sistemas y aplicaciones que permitieran la compartición de datos da lugar en muchas
ocasiones a desarrollos a medida que permitan la integración.
Esta solución del desarrollo a medida en ocasiones resulta demasiado cara e ineficiente,
pero que pasaba a ser una parte importante del trabajo de los departamentos de IT de una
compañía.
Sin embargo, si utilizamos aplicaciones que estén diseñadas para ser “intrínsecamente
interconectables” darán lugar a un conjunto de herramientas y utilidades pensadas para
dar servicio a sus clientes (estos podrán ser otras aplicaciones o usuarios) aunque estos
sean desconocidos en el momento inicial.
Si están diseñadas para ser utilizadas de manera indistinta por uno u otro cliente, esta
aplicación podrá dar servicio a múltiples clientes y ser por lo tanto reutilizable dentro de
la compañía.
84
Por todo esto, el concepto de integración de las distintas aplicaciones, sale de manera casi
automática al disponer de la posibilidad de interconectar con cualquiera.
Si cada vez más el desarrollo de servicios dentro de la empresa se va dando de acuerdo

a esta filosofía diseñada por la arquitectura, lugar a un catálogo cada vez más amplio y
reutilizable por defecto de los diferentes sistemas.
8.5. Ejemplo
Si llegamos a una compañía que ha ido creciendo de forma clásica a través tanto del
crecimiento orgánico de la misma como por la adquisición de diferentes compañías, en
multitud de ocasiones nos podemos encontrar entornos complejos de manejar.
Así, si vemos una estructura en la cual priman aplicaciones propietarias, diseñadas en

un momento dado para dar respuesta a los problemas de la compañía en ese momento,
sumado a múltiples cambios o adquisiciones de diferentes compañías a lo largo de la his-
toria (podemos pensar en un gran banco, que crece de manera propia y al mismo tiempo
por la adquisición de otros bancos en otros países).
Si planteamos su situación en un momento dado, tendremos un conjunto de aplicaciones

y sistemas, que, si bien dan servicio puntual a cada unidad en el momento de su creación,
en el momento de pasar por la integración con otros sistemas, perdemos esta facilidad.
En estos casos, si no disponemos de una arquitectura orientada a servicio, cada vez que se
quiera ofertar un nuevo servicio, se ha de desarrollar una aplicación a medida para cada
servicio, con los costes que ello tiene, no solo desde el punto de vista económico para el
desarrollo, sino desde el punto de vista estratégico por el tiempo necesario para llevar a
cabo este desarrollo.
Si por el otro lado, nos encontramos en una empresa con una estructura y arquitectura
orientada a servicios, donde los desarrollos de cada servicio, sistema o aplicación se ha
realizado pensando que este se debe de integrar con otros, por ejemplo, siguiendo en el
entorno bancario, con las aplicaciones prexistentes, con herramientas de uso, con los di-
ferentes departamentos, etc.
Tendremos distintos módulos que podremos reutilizar para lanzar el nuevo servicio, pues
en muchos aspectos tendrá elementos comunes con los servicios ya existentes dentro del
sistema.
Si lo que hablamos es de integrar otra entidad recién adquirida, en el caso de la primera

adquisición, posiblemente deberemos desarrollar una aplicación a medida para poder
acceder a los datos del sistema, pero según vamos reutilizando la entrada de datos a nues-
tros entornos será siempre igual, por lo que lo único que deberíamos rehacer será la co-
nexión con los datos antiguos.
85
Esto cada vez nos dará más servicios a reutilizar y por lo tanto menos entornos a desarro-
llar, por lo que podremos necesitar menos tiempo en la integración o creación de nuevos
servicios y tendremos mayores beneficios.
Estos cambios estructurales pueden ayudar nuevamente a cambiar la sensación que exis-
te en muchas organizaciones de que los departamentos de TI son frenos para las compa-
ñías y muchas veces un gasto necesario, para ser ayuda en transformar el departamento
en motores de innovación y de desarrollo dentro de la compañía al ser capaces de realizar
y ofrecer servicios cada vez con mayor rapidez.

Los elementos que permiten la comunicación entre los sistemas de la empresa. Como
deberíamos articular estos para que una arquitectura nos permita ser reutilizable y las
ventajas que con ello conseguiremos.
Dato importante
SOA o arquitectura orientada a servicios establece un modelo de arquitectura que

ayuda a mejorar la eficiencia, efectividad y productividad de una empresa, posi-
cionando los servicios como lo primero que debemos de tener en cuenta cuando
queremos presentar una lógica de solución de un problema, o para la consecución
de los objetivos estratégicos de la compañía, asociado a la programación orientada
a servicios.
86
9. Web Services
“Es necesario definir nuevos estándares para garantizar la seguri-
dad, la confiabilidad de las transacciones y la consistencia dentro
de los flujos de los procesos de negocio que se vean afectados; los
estándares de seguridad nos permiten autentificar usuarios y pro-
tegernos frente accesos no autorizados a la información.”
9.1. Historia
En el año 1999, los vendedores de IT introdujeron una nueva generación de soluciones
orientadas al mundo de computación en red, los servicios Web.
El desarrollo de software hasta ese momento se realizaba por parte de los cientos de desa-
rrolladores que existían, que realizaban aplicaciones, y sistemas basados en muchas oca-
siones en interfaces de conexión propietarios, que hacía complicada la interoperabilidad
entre los distintos productos.
Por un lado, los fabricantes buscaban este sistema de proteger y mantener a su cliente,
pero eso acarreaba grandes costes para los clientes, llegando a ser más delo 40% del desa-
rrollo de una aplicación el poder integrarla con los entornos existentes.
Fue HP quien propuso utilizar unos módulos de interconexión de servicios basado en la

tecnología de Internet, como aplicaciones hosting, entornos de comercio electrónico o
sistemas de gestión de recursos empresariales (ERP).
Estos eran módulos de software que intercambiaban información a través de Internet o

las redes empresariales, interoperando entre distintos tipos de hardware, sistemas opera-
tivos y lenguajes de programación.
El modularidad significaría grandes ahorros para los clientes empresariales cuando qui-
sieran afrontar el poder integrar nuevas aplicaciones con sus entornos antiguos o para
permitir integrar los softwaress de clientes y proveedores.
Rápidamente esta idea fue adoptada por otros fabricantes, que acogieron este concepto.
87
Este método para realizar las integraciones en la actualidad es a través de Web Services,
que nos permite establecer protocolos de comunicación y estándares para el intercambio
de información entre las aplicaciones.
Así, en una compañía tendremos diferentes sistemas, incluso de fabricantes diferentes,

como puede ser una aplicación de ERP (Enterprise Resource Planning) o una de gestión
de cartera de clientes y de la fuerza comercial y ambas podrán comunicarse para integrar
la información de los diferentes entornos.
El servicio web o Web Services será por tanto un componente software que expone en la
red cierta lógica de negocio y/o datos a un potencial “consumidor” (que será otra aplica-
ción normalmente) a través de una interfaz estándar y simple.
Pero cuando apareció el concepto de servicios web o Web Services, los distintos provee-
dores del mundo de las tecnologías entablaron una batalla para definir cuáles serían los
estándares.
Los estándares que debían de establecer entre los fabricantes daba lugar a una confronta-
ción que podía tener dos caminos, o bien uno se lo lleva todo e impone sus planteamien-
tos, o llegaban a un acuerdo de interoperabilidad entre plataformas incompatibles, par-
ticularmente entre los dos grandes estándares que surgieron, Java, por un lado, que fue
diseñado por Sun Microsystem y .Net por el otro que era diseñado y creado por Microsoft.
Microsoft vendría a decir en un anuncio que sería como si un comprador de un coche ve

en un concesionario independiente un coche que le gusta y lo va a pedir, pero cambia de
idea de cuál es el color que quiere y el comercial desde su terminal es capaz de poner esa
solución y en la planta de producción se cambia el color de pintado del coche en tiempo
real.
Este ejemplo nos permite al final ejemplarizar la idea detrás de los servicios web, módu-
los de software que se pueden descubrir, comunicar, invocar y relacionar entre sí, siendo
ejecutados en diferentes plataformas de software o hardware dentro de la empresa. En el
ejemplo, entre el fabricante y el concesionario independiente.
Ambos entornos de desarrollo, tanto Java como .Net tienen filosofías similares, pero
mientras se desataba esta batalla, cada uno fue consiguiendo aliados, para al final llegar al
punto en el que ninguno de los quedó como ese ganador que lo consigue todo, por lo que,
en la actualidad, lo que nos queda es dos plataformas de desarrollo, una que será Java, en
la actualidad propiedad de Oracle tras su adquisición de Sun Microsystems y otra .Net
que es propiedad de Microsoft.
88
9.2. Estándar Web Services

La definición de los estándares era un punto crucial dentro del funcionamiento de los
sistemas, para conseguir la interoperabilidad entre las diferentes aplicaciones ofrecidas
por los distintos vendedores.
Se cogieron cuatro estándares: XML, WSDL, SOAP y UDI, que son el eje de los servicios
web. Aun así, estas tecnologías están en constante evolución, pero pese a eso, son las
que han sido comúnmente aceptadas por la mayoría de las compañías de la industria del
software.
Para que los servicios web terminen de funcionar completamente, no solo necesita esos
cuatro estándares, sino que hay que basarse en estándares que estén “por encima en la
pila” (cuando decimos la pila nos referimos a los niveles de funcionamiento dentro de
la arquitectura, así los niveles más bajos definen los interfaces de comunicación entre
dispositivos hardware y con los elementos de comunicación, por ejemplo entre Reuters
de red y el software TCP/IP; los niveles más alto definen los de transporte y la capa de
aplicaciones, entre TCP/IP y los navegadores web).
En particular, era necesario definir nuevos estándares para garantizar la seguridad, la con-
fiabilidad de las transacciones y la consistencia dentro de los flujos de los procesos de
negocio que se vieran afectados. La idea de enlazar aplicaciones proviene de la necesidad
de comunicar diferentes aplicaciones de distintos departamentos, que permitan comuni-
carse entre ellos, por eso es importante garantizar el flujo y la calidad de la información
enviada.
Los estándares de seguridad nos permitirían autentificar usuarios y protegernos frente

accesos no autorizados a la información. Los estándares que nos garantizan la confiabili-
dad de las transacciones permitirán a ambas partes que la transacción se había llevado a
cabo de forma satisfactoria.
Los estándares para los flujos de los procesos de negocio nos permitirían especificar los
pasos de programación requeridos para completar las rutinas transaccionales que se pro-
duzcan en el proceso como comprobar el estado de inventariado antes de procesar una
orden de pedido.
89
9.3. Java y Sun Microsystems

Sun Microsystem, la empresa creadora de Java, es una compañía creada en 1982 para
explotar el mercado de estaciones de trabajo potentes que son utilizadas para trabajar por
científicos e ingenieros.
Si en principio su objetivo era el mercado de las estaciones de trabajo, su portfolio fue

creciendo, para llegar a tener alrededor de su procesador SPARC y su propio sistema ope-
rativo basado en Unix Sun Solaris una amplia gama de dispositivos.
Al igual que otras compañías fabricantes, que tenían sistemas basados en Unix propieta-
rios como IBM o HP, Sun Microsystems tenía servidores, puestos de trabajo, y una amplia
gama de servicios alrededor.
La fabricación de hardware empresarial para la intercomunicación de dispositivos era

su punto central, y sobre eso basaba su desarrollo, pero no era su única línea de negocio.
En el año 1995, Sun Microsystems lanzó al mercado una plataforma de programación que
permitiría a los desarrolladores crear software que podría ser ejecutado en cualquier pla-
taforma hardware o sistema operativo, a esto lo llamó Java.
Java tenía un mensaje, escribe una vez, ejecuta donde tú quieras. Los programas o mini
programas Java llamados applets eran ejecutables en cualquier entorno, se almacenaban
en un servidor y se descargaban por parte del cliente de manera temporal a través de la
red y eran ejecutables en cualquier dispositivo.
En el entorno de desarrollo de la plataforma, llegó incluso a crear unos dispositivos co-

nocidos como JavaStation, unos dispositivos que carecían de disco duro o unidades de
almacenamiento, orientadas a la ejecución de applets de Java desde un servidor remoto, y
que permitían llevar al extremo los beneficios de los sistemas basados en Java. Estas pla-
taformas desarrolladas en el año 1996 tuvieron poco impacto en el mercado, pero sirven
para dar una idea de cómo Java era un entorno que podría ser utilizado en cualquier en-
torno, desde PC, servidores, dispositivos ligeros como las estaciones Java o en teléfonos
móviles o electrodomésticos, ya que tan solo necesitaban el entorno de Java para poder
llegar a funcionar de manera correcta.
90
Esto permitió a Sun Microsystems generar unos pequeños ingresos y dominar una pla-
taforma sobre la que se podían ejecutar mini programas que sobre todo en los principios
del boom de Internet, en los finales de los años 90 y principios del 2000 le permitían
tener gran cantidad de las aplicaciones que se realizaban en Internet, realizadas sobre su
plataforma.
Tanto es así, que en año 1998 Sun Microsystems lanzó la segunda versión de su platafor-
ma de desarrollo y las tecnologías que tenía alrededor, que dio en llamar “Java2”.
Este entorno, lo dividió en varias partes, una versión empresarial J2EE (Enterprise Edi-
tion) que requería licencia, pero también otra J2SE (Standard Edition) para lo que no
había que pagar licencia, por lo que muchos desarrolladores y empresas se lanzaron por
este camino.
Además, Sun Microsystems creo la JCP (Java Community Process) que permitía entrar
a aquellas empresas interesadas en el desarrollo bajo Java a ayudar a definir la evolución
del sistema y sus aplicaciones, eso hace que rápidamente para muchos entornos de desa-
rrollo de software J2EE fuera una opción a elegir para el software empresarial, ya que sa-
bían cómo funcionaba y grandes desarrolladores como IBM o BEA se lanzaron a abrazar
esta plataforma de desarrollo.
9.4. Microsoft y .Net

Microsoft es una empresa creada en 1975 creada por Bill Gates y Paul Allen, con la idea de
dedicarse al sector de la informática. En su principio nació de la creación de un lenguaje
de programación para un tipo de sistemas concretos, como era el BASIC.
Sin embargo, el gran salto lo dio cuando lanzó al mercado DOS, un sistema operativo para
el PC de IBM, que gracias a la aparición de los clones del PC de IBM y a la estrategia de
marketing de Microsoft para que estos incorporaran su MS-DOS (Microsoft Disk Opera-
ting System) se fue extendiendo cada vez más.
Luego fue extendiendo su red dentro de los mercados de cliente y servidor, con la llegada
de sistemas operativos de servidores como el Windows NT o de puesto de trabajo como
el Windows 95 en el año 1995.
En el año 1989 lanzó un software de oficina, que llamó Office y que comenzó a crecer rá-
pidamente, hasta prácticamente pasar a ser un estándar dentro de las empresas, con su
procesador de textos, su hoja de cálculo. Continuó desarrollando software de diferentes
índoles, sin dejar de lado la plataforma de sistemas operativos, como bases de datos, siste-
mas de servidores de páginas web, herramientas diferentes para entrar en prácticamente
todas las áreas del software dentro de las empresas.
91
Microsoft, empresa líder del mercado del software en entornos de PC y servidores, contro-
laba el desarrollo de aplicaciones que se hacían para sus plataformas, ya que al diseñar el
sistema operativo definía las reglas del juego dentro de sus propios sistemas operativos.
Viendo cómo empezaban a crecer herramientas que permitían la interoperabilidad y que

ayudaban a poder ejecutar en entornos ya existentes aplicaciones basadas en plataforma
Linux bajo Java, y que este entorno iba creciendo rápidamente, desarrolló un entorno que
diese respuesta a esta demanda.
De un entorno basado en aplicaciones que se ejecutaban de manera independiente den-

tro de los puestos de trabajo, pasó a un entorno donde las aplicaciones se pudiesen ejecu-
tar a través de la red.
Para abordar esta estrategia lanzó al mercado una completa suite de productos y herra-
mientas de desarrollo que permitiera acometer este tipo de proyectos, como era el entor-
no o la iniciativa .Net. Esta permitiría ejecutar aplicaciones basadas en servicios web.
Toda la familia de productos de Microsoft, incluyendo Windows, Office, Outlook, Hotmail,

MSN, Messenger, etc. Se modificaría para ser capaces de trabajar e inter relacionarse con
la plataforma.Net. Este cambio le costó a Microsoft millones de dólares en el desarrollo y
la investigación necesarios para ser capaces de hacerlo.
Se le criticó mucho que, aunque es cierto que utilizaba los estándares definidos para Web
Services, como eran XML, SOAP, WSDL y otros estándares para poder conectar con los
elementos de J2EE, también es cierto que dentro de sus herramientas de desarrollo in-
cluían elementos que solo podían funcionar en entornos basados en Windows.
Al final la gente de Microsoft defendía que, si bien las aplicaciones que utilizasen .Net
tendrían una dependencia de los entornos basados en Windows y por lo tanto del sistema
operativo, no es menos cierto que aquellas plataformas o entornos basados en J2EE te-
nían una dependencia del lenguaje de programación, ya que tenían que ser desarrollados
en Java.
Para demostrar esto, la plataforma de .Net incluía elementos como diferentes lenguajes
de programación, como C++ o Visual Basic, que eran algunos de los más extendidos, así
como una variante del propio Microsoft de Java llamada J++.
Para la ejecución de los módulos Java desarrollados sobre J2EE, se podía utilizar cual-
quier máquina, pero siempre y cuando viniese con una “envoltura” como era la máquina
virtual de Java que permitía ejecutar ese código dentro de cualquier plataforma, ya que
era la propia JVM quien se encargaba de la traducción para la ejecución.
92
En el caso de las interrelaciones con el software propietario de Microsoft, también se daba

controversia, porque no estaba completamente abierto, sino que Microsoft generaba unas
API de comunicación, que permitían la interconexión del software que se desarrollase
con las aplicaciones de Microsoft como Office o Outlook, así como con otros software
empresariales de gran envergadura.
9.5. Otras alternativas

Otros fabricantes de software como puede ser IBM, tomaron la decisión de aliarse con
uno o con ambos, si bien Sun e IBM han sido aliados en multitud de ocasiones, hasta
llegar al punto en que IBM llegaba a vender más sistemas basados en Sun Solaris que el
propio Sun Microsystems.
Eso hizo que en el momento de llegada al mercado de Java y más con la versión de J2EE,
IBM viera el potencial de la herramienta y lo utilizase para desarrollar su propio software
como Websphere, u otros sistemas.
Sin embargo, el control de la plataforma Java era propiedad de Sun Microsystems e IBM
era simplemente un usuario, esta decidió apoyar a Microsoft a desarrollar versiones de
su entorno Web Services que fueran en un entorno abierto, como SOAP y ayudo a esta
a desarrollar especificaciones para llegar a las definiciones de WSDL y sistemas UDDI.
Con lo que IBM al final es usuaria de ambas tecnologías y con interés en el mantenimien-
to de diferentes plataformas, para evitar que una domine el mercado, se establecieran las
reglas únicas y unas altas licencias por la utilización del software necesario para llevar a
cabo estos entornos.
Las plataformas de código abierto se decantaron rápidamente por Java, ya que permitía
la ejecución de código sobre los entornos basados en Linux, también es un entorno que
en las pequeñas y medianas empresas tiene mucho poder ya que si bien Microsoft, IBM
y otras ofrecen sistemas de servidores de páginas web y de aplicaciones, la existencia
de software gratuito y fiable como es el de la Apache Software Fundation, en aquellos
entornos con menos presupuesto podían llegar a entrar en desarrollos con una menor
inversión.
Existen también otros elementos que intervienen o participan en los desarrollos, como
son la WS-I Web Services Interoperability Organization, creada por IBM y Microsoft en el
año 2002, con gran cantidad de desarrolladores como Accenture, BEA, Fujitsu, HP, Intel,
Oracle o SAP, que crean versiones o parámetros de los estándares de interconexión, XML,
SOAP, UDDI y WSDL, para que luego todas las aplicaciones puedan interconectar.
93
La existencia de este tipo de organizaciones no está exenta de ciertos problemas políticos,

ya que todas las empresas son conscientes de que quien defina los estándares mandará
en la infraestructura de desarrollo presente y futura, y todas tratan de aproximar la plata-
forma a sus sistemas.
9.6. Conclusiones
Los desarrollos de aplicaciones empresariales, son cada vez más importantes, las empre-
sas se basan en los diferentes software para tener una diferencia competitiva.
Pero como vimos en el entorno de arquitectura empresarial, ni las empresas ni las aplica-
ciones se pueden permitir hoy en día poder funcionar de manera independiente.
Entornos como Internet, o las mismas comunicaciones empresariales, obligan a que los
diferentes departamentos de la empresa estén interconectados y estas estén comunica-
das con sus clientes.
Para poder dar respuesta a estos entornos sin necesidad de que una empresa tenga todo
el software desarrollado a medida y por un único fabricante, para permitir que el software
empresarial se pueda nutrir de diferentes fuentes, por ejemplo, que en un proceso de com-
pra podamos saber si tenemos stock, asumiendo que el control del stock de la empresa
no tiene por qué realizarlo el mismo sistema que realiza la compra, es necesario que las
diferentes herramientas se puedan comunicar.
Ahora mismo en el mercado existen dos grandes tecnologías, una Java, capitaneada en la
actualidad por Oracle después de que esta comprara Sun Microsystems en el año 2009 y
otra, que sería .Net desarrollada por Microsoft.
Si bien ambas pueden perfectamente coexistir dentro de una empresa, dependiendo del
tipo de aplicaciones, del entorno sobre el que estemos realizando los desarrollos, de los
sistemas que tengamos y de los lenguajes de programación que queramos o podamos
utilizar, optaremos por una o por otra.
Siempre encontraremos un debate abierto entre los defensores de cada plataforma, y de-
pendiendo del entorno donde nos encontremos de trabajo cada una tendrá sus ventajas y
sus inconvenientes que como selectores de la tecnología deberemos de sopesar.
Dato importante
Los estándares de seguridad nos permitirán autentificar usuarios y protegernos

frente accesos no autorizados a la información.
94

• Cómo los sistemas de Web Services nos pueden servir como herramientas de in-
tercomunicación entre diferentes sistemas y crear una plataforma única sobre la
cual realizar diferentes desarrollos, con un marco de trabajo establecido y prede-
terminado.
• La evolución de las dos plataformas que dominan el mercado, como son Java y .Net
con algunas diferencias entre ellas y alguna solución alternativa.
95
10. Seguridad en los negocios

“Las políticas de seguridad de la empresa no son elementos que
funcionarán o existirán de forma autónoma, sino que serán exten-
siones de otras políticas existentes dentro de la organización, y de-
berán de asumirse como tal.”
10.1. Historia
El 24 de enero de 2008 se descubrió en Francia cómo Societe Generale, la segunda enti-
dad financiera del país por detrás de BNP Paribas, tenía un agujero de 4.900 millones de
euros en sus cuentas.
Muchos se preguntaban cómo pudo pasarle eso a una entidad de semejante tamaño
y prestigio. El problema fue que un empleado, de 31 años, con un sueldo de menos de
100.000 euros, uno de los operadores que trabajaba con futuros, había perpetrado un frau-
de por semejante cantidad.
El problema fue que, a pesar de los controles existentes, este empleado había conseguido
ir saltándoselos, para realizar operaciones inapropiadas, de tal manera que, en sus ope-
raciones con futuros, acabó generando unas pérdidas millonarias para el propio banco
donde trabajaba.
El operario que se dedicaba a la gestión de futuros sobre productos tradicionales, empezó

a realizar operaciones arriesgadas, poniendo en riesgo demasiadas posiciones, llegando
a jugarse más de 50.000 millones de euros sobre posiciones futuras del banco, saltándose
todos los controles internos y consiguiendo evitar cualquier tipo de vigilancia.
Esta anécdota que podía pasar a engrosar las páginas de economía de los periódicos
-como otras, también famosas como el caso Madoff- nos sirve de ejemplo dado que, a dife-
rencia del caso americano, Kerviel (que así se llamaba el gestor francés) pudo hacer esto,
no por su capacidad para gestionar dinero, sino porque consiguió eludir los diferentes
controles informáticos planteados por la entidad bancaria francesa.
Además, en muchas de las ocasiones, se valió de sus conocimientos de los sistemas infor-
máticos del banco para poder hacerlo.
96
Conocía el funcionamiento de los sistemas de la empresa, donde se encontraban los agu-

jeros de seguridad en sus sistemas o las claves y contraseñas necesarias para entrar a los
archivos, eso sumado a una baja aplicación de las políticas establecidas en la empresa,
que le permitía utilizar contraseñas de compañeros que se las dejaban, o que accedía a
sistemas no bloqueados de compañeros para o bien realizar las operaciones o bien simu-
lar que autorizaba sus propias operaciones desde ordenadores de los superiores, y así
eliminar las alertas que daba el sistema para evitar bloquear sus transacciones.
Durante más de un año, entre el verano de 2006 y otoño del 2007 hubo numerosas alertas
dentro de los sistemas indicando que las operaciones llevadas a cabo por Kievel supera-
ban los límites establecidos y que suponían un riesgo para la entidad.
Los problemas vienen cuando para solventar esos riesgos, el operador falsificaba correos
de sus superiores autorizando las operaciones o les sustituía dentro de los sistemas de
la compañía para autorizar sus propias operaciones, o las enmascaraba con operaciones
realizadas a través de cuentas de sus compañeros a los que le había pedido la contraseña
de acceso.
Este no es el único caso en que la seguridad de una empresa puede costarle millones, y no
necesariamente porque no lo tengan, sino porque las políticas establecidas dentro de la
compañía no son lo suficientemente fuertes o consistentes.
Esta ausencia de seguridad, o los no adecuados niveles dentro de la compañía, pueden de-
generar en pérdida de ingresos, si los sistemas informáticos de la compañía no funcionan
de manera adecuada, pude producir una caída de los ingresos que se produzcan.
Incluso un fallo de seguridad puede llevar a que la empresa deje de operar durante un
periodo de tiempo dado.
Además, se puede producir una pérdida de la imagen de la empresa, con la consecuente

bajada de valor de mercado si esta cotiza en bolsa, con mayor motivo, esta pérdida de
imagen puede ser altamente perjudicial para la empresa.
Podemos incurrir en acciones de tipo penal o legal, en el caso del banco, al darse lugar
un fraude. En el caso que comentamos, existieron múltiples investigaciones tratando de
determinar las diferentes responsabilidades y esto podía haber derivado en la pena de
cárcel, no solo de la persona que cometió el fraude sino de los dirigentes responsables de
la empresa, ya que bajo su mandato se habían producido esas acciones contra la ley por
parte de la compañía.
97
Otro de los riesgos que se pueden dar es de seguridad en los sistemas es la de la dismi-
nución de productividad por parte de los empleados, tendremos que valorar el justo equi-
librio entre la seguridad y la productividad, así si protegemos en exceso los activos y los
datos, es posible que las personas que deban acceder a ellos no puedan hacerlo de manera
adecuada y su rendimiento dentro de la empresa se vea afectado por ello.
Los diseños de seguridad dentro de la empresa pueden llevar a una serie de costes ope-
rativos derivados de su implantación, pero los costes en los que incurriríamos en caso de
no hacerlo pueden llegar a ser mayores. El problema es la justificación de los mismos, ya
que en numerosas ocasiones nos encontramos con que el establecimiento de las políticas
no aporta un beneficio inmediato para la empresa y desde distintos ámbitos nos podemos
encontrar personas en contra de su implantación en la empresa.
10.2. El proceso de la seguridad

La seguridad en los entornos informáticos, no consta de un único paso, sino que es un
proceso dentro de la empresa. Asumiendo que la seguridad absoluta no existe, lo primero
que deberíamos hacer es montar una infraestructura de seguridad para prevenir posibles
incidencias y protegernos frente a las amenazas que puedan acontecer.
Necesitaremos también tomar medidas contra los posibles daños y que nos permitan
detectar cuándo, dónde, por quién y con qué alcance hemos sido atacados o cómo han
sido vulnerados nuestros sistemas. Podremos establecer políticas de respaldo que nos
permitan seguir funcionando si es posible, con entornos distribuidos donde repartamos
la información y los datos o con sistemas de respaldo que funcionen en un entorno dis-
tinto o distribuido.
Por último, implicará un plan de reacción, tomaremos las medidas para recuperarnos del
suceso, recuperar los activos, o los daños producidos sobre estos.
Para poder hacer esto habrá que actuar en cuatro niveles diferentes.
10.3. Nivel directivo

Para que el proceso de seguridad sea exitoso dentro de la empresa, este ha de venir im-
pulsado desde los niveles de dirección de la empresa, pero no solo se debe dar el visto
bueno, sino que se debe demostrar que la seguridad y la gestión de los diferentes riesgos
tecnológicos es un elemento de gran importancia dentro de las organizaciones.
Para que la seguridad sea un hecho dentro de la empresa, esta debe de afectar a todos los
empleados por igual, no se puede esperar que los empleados cambien su comportamiento
e introduzcan o incorporen las diferentes estrategias y políticas de seguridad si sus supe-
riores no la respetan o no la incorporan a su día a día.
98
Desde la propia dirección se deben incorporar las acciones que trabajen en pro de la segu-
ridad de la empresa, no se debe esperar por parte del resto de los empleados.
En multitud de ocasiones, con adquisiciones de nuevos sistemas, o con integraciones o

adquisiciones de otras empresas, la seguridad no es uno de los valores puestos en primer
plano por parte de la dirección y esto puede ser aprovechado por hackers para tratar de
atacar a la empresa. Conseguir modificar esto es una función de la dirección de la com-
pañía.
10.4. Políticas de seguridad

El establecimiento dentro de la compañía de políticas de seguridad lo que nos permitirá
es evitar el uso indebido de los sistemas informáticos, deberíamos crear y establecer po-
líticas que nos permitan ayudar a establecer los niveles de seguridad deseados dentro de
la compañía.
Para la creación de las políticas de seguridad se deben realizar previamente una serie de
análisis que generarán y descubrirán las necesidades de la empresa a nivel de seguridad,
que nos permitan conocer los riesgos a los que nos enfrentamos, que determinen cuál es
la cultura de la organización y cuáles serán los costes de aplicación de las políticas, así
como qué beneficio nos dará el implantarlas.
Para crear las políticas se debe de generar un documento específico, claro, conciso y rea-
lista. Una política estará bien escrita si se puede generar de ella una lista de comproba-
ción de su cumplimiento.
Para ello, las políticas de seguridad deberán establecer cuáles son los activos que se pro-
tegen y hacerlo de manera razonada, si no sabemos por qué, muchas veces no llegaremos
a implantar dicha política.
Se deberá de asignar a una persona o departamento responsable de dicha protección,

para que esta llegue a buen término.
Describirán cuáles son las acciones o los pasos que se consideran aceptables dentro de la
compañía y cuáles no se deben permitir en ningún caso, de forma clara.
Establecerán cuáles son las consecuencias de la violación o vulneración de las políticas

de seguridad para los usuarios de la empresa.
Por último, dentro de las políticas se debieran incluir también procedimientos para resol-
ver los problemas derivados de la aplicación de las políticas de seguridad en la compañía.
El establecimiento de estas políticas no solo es bueno para la organización, sino que res-
tringen su responsabilidad en caso de que un empleado (como en el caso de Societe Ge-
nerale) se las salte.
99
Se pueden establecer políticas que definan el uso aceptable de los sistemas informáticos
y del acceso a la información por parte de los diferentes usuarios.
Podemos optar también por establecer políticas de tipo autorización, donde lo que se defi-
ne son los niveles de acceso de cada usuario y el tipo de información accesible, de acuerdo
a los diferentes niveles que hayamos establecido.
Las políticas de seguridad de la empresa no son elementos que funcionarán o existirán de

forma autónoma, sino que serán extensiones de otras políticas existentes dentro de la or-
ganización, y deberán de asumirse como tal. Por ejemplo, es posible que existan políticas
de igualdad de oportunidades para evitar y combatir el acoso sexual o la discriminación,
pues las políticas de seguridad deben entrar de forma natural como cualquiera dentro de
la organización de la compañía.
Para que sea efectiva como cualquier otra política existente dentro de la empresa, esta
debe de ser promovida e impulsada por parte de la dirección de la empresa y debe ser
conocida y comprendida por parte de todos los empleados de la compañía.
10.5. Procedimientos de seguridad

Los procedimientos de seguridad suponen el nivel donde se va a producir la transición
entre los documentos y políticas de seguridad que hayamos creado y la aplicación diaria
de las políticas dentro de nuestra propia organización.
Serán el entorno donde generaremos ejemplos detallados de las diferentes prácticas que
se deben impulsar, desalentar o prohibir dentro de la organización de acuerdo a las polí-
ticas establecidas.
En este nivel deberíamos definir elementos tales como la obligatoriedad de existencia de

un usuario para cada empleado, con su propia contraseña y las políticas de definición de
la contraseña como la fortaleza de la misma, número de caracteres mínimo, combinación
de caracteres o duración de la misma.
Se definirán políticas de actualización de componentes, del software, del sistema operati-

vo, antivirus, etc.
100
10.6. Herramientas de seguridad

Para poder aplicar la correcta seguridad dentro de la empresa, no es suficiente con crear y
diseñar unas políticas de seguridad, sino que deberíamos proveernos de las herramientas
adecuadas que nos permitan su correcta implantación.
Así, será necesario seleccionar las herramientas necesarias a nivel de software, hardware
y herramientas de red que nos permitan garantizar las diferentes políticas establecidas.
A la hora de buscar la tecnología y las herramientas necesarias deberíamos actuar con

cuidado, ya que posteriormente y en gran medida dependeremos de ellas.
Existen herramientas y tecnologías aún inmaduras, que prometen muchas posibilidades,

pero el hecho de estar en constante evolución puede hacer que no sean las idóneas en un
momento dado.
Por otro lado, deberíamos comprobar la existencia de estándares y el seguimiento de las

legislaciones vigentes por parte de las diferentes herramientas, así como la correcta ac-
tualización de las mismas, dado que el mundo de la seguridad tecnológica, como casi todo
en los entornos de las tecnologías de la información y las comunicaciones se encuentra
en constante avance y si no garantizamos correctamente las actualizaciones de los siste-
mas, podemos quedar desfasados.
Entre las herramientas que deberíamos de seleccionar se encuentran las referidas a:
• Software de antivirus: hoy por hoy, son imprescindibles en muchos casos o en-
tornos y se ha llegado a plantear que dependiendo del sistema operativo que se-
leccionemos, o el entorno donde nos movamos, podrían no ser necesario, pero la
realidad es que ningún entorno es totalmente seguro ni está completamente libre
de virus, por lo que un sistema antivirus fiable y que se actualice periódicamente
es imprescindible.
• Cortafuegos: dado que hoy en día es impensable una empresa sin conexión a In-
ternet (es prácticamente obligatorio para algunos trámites administrativos y en
general, es un entorno de uso común) será necesario una herramienta que ayude a
evitar los ataques, pero para su correcto funcionamiento ha de estar configurado y
actualizado de acuerdo a nuestras políticas e intenciones.
101
• Herramientas de Back-Up: poder recuperarnos a un estado anterior, muchas veces

se ve para entornos susceptibles de fallos informáticos o de caídas de sistemas,
pero para recuperarnos de un ataque o un virus, tener los datos protegidos es algo
fundamental.
• Herramientas de detección de intrusos: aquellas que nos permitan detectar un uso

fraudulento de los accesos o intentos de acceder a nuestros sistemas.
• Codificación de la información: utilizar información encriptada, nos puede prote-

ger contra pérdidas involuntarias o dificultar el acceso a los sistemas por parte de
los intrusos en nuestra red y la obtención de los sistemas.
• Cualquier otra herramienta que nos planteemos y pueda sernos de utilidad
A la hora de protegernos tendremos que tener en cuenta no solo estas herramientas, sino
que al final, ellas son solo herramientas tecnológicas al servicio de la organización, por
lo tanto, la creación e implantación de las diferentes políticas, así como su seguimiento y
observación por parte de los empleados es fundamental.
Para conseguir que estas políticas lleguen a ser eficaces debieran venir impulsadas y ava-
ladas por la dirección de la compañía, no solo de palabra, sino también con su ejemplo,
para evitar problemas futuros en el funcionamiento de la empresa.

Cómo es importante establecer políticas de seguridad dentro de la empresa y los riesgos

derivados de la no creación de estas políticas, así como algunas herramientas que no pue-
den ayudar a implantar dichas políticas.
Dato importante
Los procedimientos de seguridad suponen el nivel donde se va a producir la transi-

ción entre los documentos y políticas de seguridad que hayamos creado y la aplica-
ción diaria de las políticas dentro de nuestra propia organización. Serán el entorno
donde generaremos ejemplos detallados de las diferentes prácticas que se deben
impulsar, desalentar o prohibir dentro de la organización de acuerdo a las políticas
establecidas.
102
11. Amenazas y vulnerabilidades

“Desde lal dirección de una empresa, se debe evaluar el valor en la
empresa de los activos de información, medir cómo pueden ser com-
prometidos y establecer un conjunto de actividades que ayuden a
mitigar el riesgo y establecer las actuaciones de respuesta.”
11.1. Las amenazas

Las amenazas a la seguridad digital dentro de la empresa se pueden presentar de muchas
maneras diferentes, pero podremos agruparlas dentro de tres categorías: los ataques de
red, las intrusiones y el código malicioso.
Los ataques de red serán aquellos que se realizan a través de Internet, pueden perseguir
degradar el rendimiento de nuestras redes o deteriorar nuestros servicios a través de la
red, como el correo electrónico o cualquier otro servicio on line como un portal de venta
electrónico que se esté ofreciendo desde nuestra empresa, así como persiguen provocar
daños que nos puedan costar dinero dentro de la empresa.
Por ejemplo, se puede producir lo que se llama un ataque de denegación de servicio, por
el cual los ordenadores se ven asediados con multitud de solicitudes llegando a saturarse,
provocando que se produzca una caída dentro de los sistemas y generando que no poda-
mos dar respuesta a las solicitudes reales que se estén produciendo.
Es una forma sencilla de atacar a las empresas y que no es fácil de repeler, ya que desde el
punto de partida y sin sistemas para ello, resultaría complicado detectar qué solicitudes
son genuinas y cuáles son falsas.
Lo bueno de esto es que con el software adecuado es más fácil repelerlos y además rara
vez causan fallos permanentes dentro de los sistemas empresariales, solo caídas tempora-
les del servicio, a pesar de esto, si contamos con un portal de comercio electrónico dentro
de nuestra empresa dejaríamos de dar servicio durante un periodo de tiempo o se podría
quedar nuestra compañía sin sus servidores de correo electrónico operativos durante un
tiempo.
Otra de las posibles amenazas venía a través de las intrusiones, se diferencian de los
ataques a través de la red en que estos realmente buscan entrar en nuestros sistemas, en
ocasiones para conseguir información de la empresa.
103
Muchas veces, estos accesos se consiguen de forma fácil, por lo que se llama ingeniería
social, sustituyendo a un usuario propio de nuestra empresa y entrando dentro de nues-
tras redes haciéndose pasar por él o buscando agujeros dentro de la seguridad de nuestra
empresa y entrando por ellos.
En muchas ocasiones, lo que llamaremos los hackers que quieren entrar y atacar nuestra
compañía están al día de los agujeros de seguridad detectados en los diferentes sistemas
operativos y lo único que hacen es buscar si no hemos aplicado el parche correspondiente
y, de acuerdo a esto, realizar el ataque a nuestros sistemas.
Muchas veces ni siquiera tiene que ser así, un visitante de nuestra empresa puede ver
cómo en el monitor de un usuario existe un post-it con la contraseña de acceso y su nom-
bre de usuario y después de manera remota intentará acceder.
A veces, ni siquiera eso es necesario: un usuario descontento con nuestra compañía en-
trará en sistemas a los que no debiera para borrar información o para pasársela a la com-
petencia.
El verdadero problema de las intrusiones es que sean realizadas por personal ajeno o per-
sonal propio, una vez dentro de nuestra red el usuario tendrá acceso a todos los datos que
pueda de acuerdo a los niveles de servicio otorgados y puede generar grandes destrozos.
En ocasiones, se han dado casos de usuarios que accediendo a los sistemas de una com-
pañía hacen algo como generar un comunicado de prensa con intenciones que pueden
hacer variar de manera artificial la cotización de las acciones, provocando grandes pér-
didas e incluso multas posteriores a la compañía por generar esa información, aunque la
información no provenga del interior de la misma, sino de un ataque externo a nuestros
sistemas.
En otras ocasiones, si ese intruso ha actuado de mala fe, se pueden haber producidos pe-
queños cambios, o tan solo la creación de una puerta trasera que les permita en el futuro
un nuevo acceso para poder seguir accediendo a nuestra información y revisando lo que
quieran de nuestra empresa.
Por esto, el tener control sobre los accesos es algo importante y no hacerlo puede conlle-
var grandes costes para las compañías.
El tercer tipo de amenaza a la que deberíamos hacer frente dentro de las empresas era el
código malicioso. La diferencia con las anteriores es que no suele ser tan dirigida contra
nuestra compañía, sin embargo, lo que nos puede producir es ataques indiscriminados
contra ciertos tipos de tecnología.
104
Estos son los producidos por los diferentes niveles de malware, como el SQL Slammer,
que en enero de 2203 generó ataques contra diferentes bases de datos, que provocó en
enero de 2003 la parada del servicio telefónico de Finlandia o la caída de 13.000 cajeros
del Bank of America. Otros, por ejemplo, como el Código Rojo no solo atacó a las em-
presas con servidores web de Microsoft, sino que les hizo más vulnerables a ataques de
denegación de servicio y se calcula que costó más de 2.600 millones de dólares limpiar
los problemas generados, o el mencionado anteriormente I Love You, que atacó sistemas
a nivel mundial de manera indiscriminada.
Por lo tanto, las diferentes amenazas pueden costar mucho a las compañías, por ejemplo,
un empleado de banca, que durante un fin de semana de vacaciones entró en los sistemas
y lanzó un ataque de DoS (Denegación de Servicio en inglés) contra la red del sistema
para acabar provocando, que mientras los responsables de sistemas intentaban corregir
estos problemas, cambiar la pagina web del banco de tal forma que cuando los usuarios
querían entrar a la web, acababan en una página pornográfica.
Mientras trataban de corregir este problema, lanzó un ataque con un virus a los sistemas,
de tal forma que, para el martes, el banco prácticamente tenía que trabajar con papel y
lápiz hasta que fueron capaces de corregir los problemas generados.
Por lo tanto, no es solo que exista uno de los tres tipos de amenazas, sino que estos pue-
den combinarse para generar una tormenta perfecta para la seguridad de los sistemas
empresariales.
Hemos de tomar las medidas adecuadas y prepararnos para ello.
11.2. El método de funcionar

Las empresas necesitan técnicos especializados en seguridad informática, pero no ha de
recaer sobre estos la tarea de proponer o realizar un plan de seguridad para la compañía,
sino que esta ha de recaer sobre personas de la dirección. Para hacer esto podemos seguir
una serie de pasos
De la misma manera que las empresas no contratan guardias jurados encargados de la

seguridad que vayan armados para evitar que se hagan fotocopias, ni se guarda el dinero
de la compañía en un cajón sin vigilancia, las mismas ideas han de aplicarse a la hora de
establecer cuáles son los activos digitales de la compañía y decidir cuánta protección
requiere cada uno de ellos.
En ocasiones, puede parecer que los métodos a seguir solo son abarcables en grandes
compañías, pero no es así, en pequeñas y medianas empresas también son abarcables,
realizando tareas de optimización inteligente.
105
Lo necesario en una pequeña compañía es igualmente definir cuáles serán estos activos,
probablemente respecto a una gran compañía, solo unos pocos sean los esenciales, o in-
cluso en muchos casos nos vendrá marcado por la legislación existente el nivel de protec-
ción que deberíamos darles, como por ejemplo en España por la LOPD (Ley Orgánica de
Protección de Datos) y por la LSSI (Ley de Seguridad de los Sistemas de la Información).
Después, este tipo de pequeñas empresas debieran recurrir a proveedores externos de
servicios para poder detectar quiénes son las personas y procesos que afectan a estos
activos esenciales.
También es necesario que se ocupen de los demás principios que integran el marco de
una solución: las políticas, los instrumentos y las técnicas de seguridad, el software segu-
ro, la gestión de la configuración y demás elementos. Afortunadamente, es posible hacer
todo esto con unas sencillas y simples acciones.
Lo primero será asegurar el perímetro de seguridad de la empresa, para ello podemos ins-
talar una serie de componentes asequibles, que en muchas ocasiones nos encontraremos
en los propios sistemas de servidor como serán los firewalls, un software de acceso a una
red privada virtual, para poder acceder en remoto, y sistemas de detección de virus en los
servidores, sobre todo en el servidor de correo electrónico.
El software de correo electrónico debería de ser el único tráfico que se produzca fuera de
nuestra red privada virtual (VPN) salvo que tengamos una página web.
Si no tenemos a una persona adecuada para llevar a cabo estas tareas podemos buscar un
proveedor de servicios de seguridad para que se encargue de la labor de instalar y confi-
gurar adecuadamente estos tres componentes, así como recomendarnos el software más
adecuado para cada caso.
Se necesitará la colaboración de los profesionales internos o externos para revisar que

todo funciona de manera correcta, así como para comprobar que se ha instalado de ma-
nera adecuada.
Si tenemos aplicaciones accesibles para el público también será necesario realizar prue-
bas ocasionales de que estas funcionan de manera correcta y que se puede acceder en
todo momento a ellas, así como si presentan vulnerabilidades o si se puede penetrar a
nuestros sistemas a través de ellos.
También será necesario instalar en todos nuestros equipos software de protección como
antivirus y firewalls, en los ordenadores de sobremesa, los portátiles y los diferentes ser-
vidores. Actualmente, estos programas no son demasiado caros además de que los po-
demos adquirir en cualquier tienda informática, o con los equipos o a través de Internet.
106
Además, será necesario habilitar la actualización automática de todos los ordenadores

conectados a Internet, ya que muchas veces los diferentes parches que se pueden aplicar
al sistema operativo o las diferentes aplicaciones, son de tipo de correcciones de segu-
ridad y así garantizaremos que cuando los proveedores las distribuyan, se instalarán en
nuestros sistemas.
Asimismo, suele ser interesante seguir las guías de protección que estos recomiendan y
que si no tenemos estarán disponibles a través de Internet.
Otra de las tareas que podremos realizar dentro de nuestra empresa, independientemente
de su tamaño, será comunicar las diferentes políticas de seguridad que estemos implan-
tando, así como insistir en su obligado cumplimiento por parte de todos nuestros emplea-
dos.
Hay que asegurarse y garantizar que todas las personas de la empresa son conscientes del
grado de implicación que puede tener utilizar software potencialmente malicioso, como
pueden ser redes para compartir archivos (P2P o cosas por el estilo para descargar música
o películas) así como programas no seguros de mensajería instantánea (aunque los siste-
mas de grandes proveedores o de tipo empresarial son entornos seguros).
Asimismo, suele ser interesante que el personal de IT esté al tanto de los diferentes bole-
tines de seguridad asociados con nuestras aplicaciones, para que sepamos que posibles
amenazas a nuestra seguridad se pueden producir.
Garantizar que la lista de usuarios de la empresa, así como sus privilegios esté al día es
algo también útil e importante, ya que una persona enfadada por un despido puede cau-
sar grandes destrozos dentro de los sistemas empresariales.
Otra de las políticas adecuadas será el uso de software empresarial genuino que nos ga-
rantice por parte del proveedor el funcionamiento y las actualizaciones del mismo.
Dato importante
Hay que asegurarse y garantizar que todas las personas en una empresa son cons-
cientes del grado de implicación que puede tener utilizar software potencialmente
malicioso, como pueden ser redes para compartir archivos, así como programas no
seguros de mensajería instantánea.
107
11.3. Conclusiones
Las empresas no pueden permitirse el lujo de responder a todas las amenazas de seguri-
dad de la misma manera ni con el mismo grado de agresividad. Aunque pudieran hacerlo,
no sería adecuado desde el punto de vista empresarial.
Los directivos deben examinar cuáles son los riesgos con más probabilidades de materia-
lizarse y cuáles son aquellos que podrán producir más daños o daños más graves dentro
de la empresa y después deben dedicar los fondos en aquellas áreas donde, con esta infor-
mación, consideren más útiles.
No se trata de un cálculo que se realice una única vez y nos sirva para siempre, ya que
constantemente están apareciendo nuevas amenazas, nuevas capacidades tecnológicas
o nuevos riesgos dentro de nuestra propia compañía, sin embargo, el proceso de medita-
ción y reflexión sobre estos es siempre el mismo.
No se quiere decir con esto que los razonamientos sobre los que se basa la gestión de
riesgos sean sencillos, de hecho, para muchas personas estos pueden ser extraordinaria-
mente complejos, pero las actitudes de los directivos hacia el riesgo y su gestión general-
mente lo son y dependerán en muchas ocasiones de su forma de ser o de pensar.
La dificultad de calcular los costes y las probabilidades añade una variable que condi-
ciona y que da mayor complejidad al cálculo. No todos los riesgos, además, podrán ser
contrarrestados por acciones bien definidas por la dirección. En algunas ocasiones, no
hay ninguna acción viable que permita abordar un riesgo específico, en otras abordar un
riesgo grave puede resultar prohibitivamente costoso.
La cuestión más importante de la que habrá que ser conscientes es que todos los casos
van a entrañar soluciones de compromiso empresarial.
Finalmente, las decisiones sobre la seguridad y sus riesgos no serán más que una solu-
ción del tipo coste-beneficio como otras muchas decisiones de tipo empresarial que ha de
tomar la dirección.
Por lo tanto, como hemos dicho en multitud de puntos, no es una tarea que deba de que-
dar únicamente a cargo de los técnicos, sino que la dirección de la empresa deberá invo-
lucrarse, cada uno de acuerdo a su nivel, pero las decisiones son de tipo empresarial.
108

• Crear un entorno de seguridad en la empresa es algo imprescindible, deberíamos

diferenciar los diferentes niveles y necesidades para cumplir con los objetivos.
• Deberíamos evaluar cuáles son los riesgos de nuestra empresa y cómo proteger-
nos frente a ellos, así como el coste asociado para hacerlo.
• Hay amenazas ahí fuera y deberíamos ser conscientes de ello para diseñar la forma
de trabajar de nuestra empresa.
109
12. Malware
“Dentro de los entornos de software existen software creados y di-
señados para atacar a los sistemas, existen muchos niveles, desde
los menos agresivos y nocivos para la compañía como pueden ser
entornos que nos ejecuten publicidad dentro de nuestros sistemas
o que nos ralenticen las máquinas hasta software que conviertan
nuestros sistemas en zombis al servicio de redes de mala gestión.”
12.1. Introducción al concepto de malware

El malware es el nombre con el que denominamos a todo tipo de software malicioso (pro-
viene del inglés malicius software) que es susceptible de ser ejecutado en nuestros orde-
nadores sin nuestro conocimiento y/o autorización.
En el año 1949 unos programadores crearon un sistema denominado “Core War” que era
un software que reducía la memoria de las máquinas y se propagaba a través de la red.
Si bien este no es un software creado en sí con intenciones dañinas, sino a modo de prue-
ba o testeo, dio lugar años más tarde, en 1972, a lo que es comúnmente conocido como el
primer virus, que es “Creeper”, un programa que funcionaba dentro de Arpanet, que, si
bien no hacía nada malo, sí que analizaba la propagación dentro de dicha red.
Lo único que hacía el “Creeper” era escribir un pequeño fichero en el que decía: “I’m the
creeper, catch me if you can”, o en castellano “Soy la enredadera, atrápame si puedes”. El
virus no era algo malicioso, sino que se copiaba y saltaba de un ordenador a otro, elimi-
nándose del anterior.
Para conseguir eliminarlo, se creó un software denominado el “Reaper”, o el segador, que

buscaba al “Creeper” y lo eliminaba, propagándose automáticamente de un ordenador a
otro buscándolo, en realidad no era más que un virus igual, pero de efecto contrario, ya
que igualmente se propagaba por la red. Como vemos, hace ya décadas que existe el en-
torno de crear un software que puede propagarse de forma autónoma por la red y puede
causar efectos no deseados por el usuario, ya que se ejecuta de forma autónoma.
110
Existen numerosos tipos de malware, no todos funcionan o se comportan igual, por lo que
iremos viendo los diferentes softwares y en qué consisten, para poder nombrarlos con
la propiedad adecuada. Si bien esta lista puede servir de base, no debe de tomarse como
los únicos modelos existentes en el entorno, ya que constantemente se están buscando
nuevas formas de atacar sistemas y esto puede variar.
Los podríamos categorizar en tres grupos, aunque ninguno de ellos excluyente, ya que el
mismo programa puede realizar varios tipos de funciones, lo haremos en función de las
consecuencias o acciones que genera:
• Malware infeccioso: dentro de esta categoría entrarían los sistemas más conocidos
de todos, como serán los virus y los gusanos, entrarán en esta categoría aquellos
que como el “Creeper” tengan intención de propagarse por la red.
• Malware oculto: es aquel cuya intención principal es la de permanecer oculto y

no ser detectado, que pueden generar puertas de acceso a los sistemas o rutas de
ataque posterior.
• Malware para obtener beneficio: si bien pareciera que hablamos siempre de crear
destrucción o modos de acceso para coger información o eliminarla, entrarían den-
tro de las categorías de malware aquel software cuyo único propósito es generar
un beneficio a su creador, bien en formato de publicidad o mediante otra forma de
generar dinero.
12.2. Malware infeccioso

Dentro de la categoría de malware infeccioso, como hemos dicho, entrarían dos grandes
grupos de software malicioso, que a su vez puede subdividirse en múltiples categorías,
según cómo funcionen y cómo ataquen a los sistemas. Su principal característica es la de
propagarse por Internet o por nuestras redes, o a través de cualquier otro medio, por CD,
USB, correo electrónico, etc.
12.2.1 Virus
Si bien un virus es un tipo de software informático (malware) con la intención de alterar
el funcionamiento normal de una máquina sin conocimiento de su usuario y con la capa-
cidad para propagarse entre distintos sistemas, existen multitud de maneras o de siste-
mas distintos. En ocasiones oímos mencionarlos en su forma genérica, otras lo haremos
especificando qué tipo de virus es, igual que sucede con los virus sanitarios, que podemos
decir que tenemos un virus o referirnos a la forma concreta de ese virus.
111
De acuerdo a su funcionamiento podrán ser:
• Virus residente: es aquel que se aloja en la memoria del sistema, con el objeto de
controlar todo lo que pasa por ella y que irá infectando los archivos que pasen por
la memoria RAM de la máquina.
• Virus de acción directa: al contrario que los anteriores, en lugar de colocarse en la

memoria y estar en funcionamiento constante, estos se ejecutan de manera inme-
diata, hacen su función de propagación y la tarea para la que hayan sido diseñados.
• Virus de sobre escritura: se caracterizan por destruir la información de los ficheros

a los que infectan, ya que sustituyen los datos que tuvieran por cualquier otro con-
tenido, consiguiendo que estos archivos sean inservibles.
• Virus de boot o de arranque: son aquellos que se sitúan en el sector de arranque o

de inicio de un disco o de un CD, por lo tanto, infectaran en el momento que inten-
tamos acceder a estos entornos, por ello su propagación se suele hacer a través de
unidades que podamos compartir, antiguamente disquetes, hoy CD, DVD o llaves
USB.
• Virus de enlace o directorio: son aquellos que se sitúan en una dirección de acceso
del sistema operativo, para que este los seleccione y así infectar al sistema.
• Virus polimórficos: son aquellos capaces de cambiar de forma o estructura tras su

ejecución. Cada vez más los virus intentan no solo aprovecharse de ciertas vulne-
rabilidades o formas de funcionar de los sistemas, sino que quieren evitar al soft-
ware que los rastrean (antivirus) y se ocultan y cambian su forma de ser para tratar
de evitarlos. Pueden recurrir a técnicas de cifrado o enfrascado.
Los virus informáticos, pueden no ser de un único tipo, ya que en multitud de ocasiones
incluyen varias formas de actuar, pero para funcionar dependen de una activación o eje-
cución por parte del usuario, o bien insertar el disco en el caso de los de boot, o ejecutar
el programa que los contiene, de forma intencionada o no.
112
12.2.2 Gusanos
La característica que diferencia a un gusano de un virus, es que el primero funciona de
forma autónoma y se propaga sin necesidad de ninguna intervención por parte de un
usuario, así, no es necesario poner ningún disco o ejecutar un archivo que nos llegue por
correo electrónico para resultar infectados, sino que lo hace él solo de forma independien-
te.
El primer gusano como tal causó problemas y pérdidas económicas se remonta al año
1988 cuando se propagó el gusano Morris. Este se aprovechaba de una vulnerabilidad en
ciertas versiones de Unix para auto enviarse y propagarse a través de la red. Su autor fue
detenido y condenado.
Actualmente, muchas veces los gusanos son incorporados dentro de la categoría de los
virus, ya que combinan la auto propagación con las características de infección propias
de los virus, la funcionalidad del gusano es llegar al mayor número de sistemas posible
y dentro, suele incorporar funciones de cualquier otro sistema malware como los de tipo
“oculto”.
12.3. Malware oculto

Para que el malware funcione de forma eficaz, tiene que permanecer oculto, para que el
usuario no lo detecte y no lo quite rápidamente del propio sistema.
Dentro de los malware de tipo oculto existen a su vez diferentes categorías, y muchas ve-
ces nos referiremos a ellos en función de su funcionamiento o funcionalidad.
12.3.1 Troyano
El troyano como tal no realiza ninguna función específica, sino que va asociado a otros ti-
pos de malware. La función de un troyano es permanecer oculto dentro de otro programa
o sistema y cuando este es llamado, saldrá a la luz. Normalmente, lo que harán será alojar
un huésped que es quien realmente es el malicioso.
En ocasiones se visten de “troyano” algunos softwares que hacen funcionalidades útiles,

pero que al mismo tiempo nos arreglan algo, introducen otra función que será dañina
para nuestros sistemas.
113
12.3.2 Puertas traseras

La intencionalidad de este tipo de software es la de producir formas de acceso a nuestras
máquinas para que puedan o bien ejecutar otro tipo de programas de manera remota o
conseguir información o acceso a los sistemas de manera constante, sin necesidad de
credenciales especificas.
Otra característica de este tipo de aplicaciones es la posibilidad de tomar control de nues-

tras máquinas para desde ellas, realizar otro tipo de actividades, así entran a formar parte
de lo que se llaman redes de zombis que son conjuntos de máquinas que se pueden con-
trolar de manera remota, bien para ejecutar ataques de DoS (Denegación de Servicio) o
para enviar Spam, sin conocimiento del usuario.
Con esto, redes de hackers, se autofinancian, gracias al control de miles de máquinas que
les permiten funcionar o conseguir beneficios por la venta de los envíos o los ataques.
12.3.3 Rootkits
Son sistemas que modifican la máquina que están atacando para permanecer ocultos e
indetectables y que profieren derechos de control a los programas.
No necesariamente tienen que ser con objetivos maliciosos, ya que uno de los ejemplos
más claros de este tipo de programas, fue el que creo Sony como protección anti copia
dentro de sus CD de música, aunque posteriormente se vio que era pernicioso y podía ser
vulnerado, se incluyó en multitud de CD de música y generó un escándalo de considera-
bles dimensiones para la compañía.
12.3.4 Drive-by-Downloads
Según Google, hace unos años, en el 2007, publicó que una de cada diez páginas webs
existentes en el mundo, de forma consciente o no, incluyen pequeñas ejecuciones que
permiten instalar programas dentro de las máquinas del usuario. Muchas veces, estas
páginas lo harán de forma consciente porque buscan atacar al propio usuario, otras veces
lo es de forma inconsciente, ya que la página que nosotros estaremos consultando ha
sido atacada y contiene en su interior este código malicioso que busca infectar nuestra
máquina.
114
12.4 malware para obtener beneficios

Una vez que se ha conseguido entrar en una máquina, si lo que nos ataca es un virus, bus-
cará la destrucción de nuestros ficheros o de nuestros archivos, pero si, por el contrario,
la intención del programa es conseguir beneficio existen muchos métodos para hacerlo.
Según el método utilizado, será de una u otra categoría.
12.4.1 Realizar llamadas telefónicas o Dialer

Este tipo de software ha caído algo más en desuso en aquellos entornos con conexiones
a través de redes ya que lo que hacían es utilizar el modem del ordenador para realizar
llamadas a líneas de tarificación especial, que añadían coste adicional a la factura de telé-
fono y permitían ganancias a los receptores de las llamadas.
Sin embargo, la llegada de las líneas ADSL o de fibra, que realizan conexiones constantes
a través de la red y no por llamada de teléfono han dejado estos sistemas desfasados.
12.4.2 Mostrar publicidad

Dentro de esta categoría existen varios tipos de software, según su verdadera funcionali-
dad, que nos permitirá o bien mostrarnos publicidad dentro de nuestra máquina lanzando
sistemas de pop-ups o mediante la ejecución de aplicaciones de publicidad en cuyo caso
estaremos hablando de AddWare.
Si la función de la aplicación es la de obtener información de nuestro sistema, como qué

páginas visitamos o nuestra libreta de correo electrónico, para aumentar la cantidad de
direcciones útiles (para posibles entornos de Spam) en ese caso estaremos hablando de
sistemas de Spyware.
Otra función de este tipo de software puede ser la de mostrar información en nuestro
navegador cambiando la configuración del mismo, estableciendo una nueva página de
inicio o redirigiendo nuestras búsquedas hacia páginas prestablecidas, en este caso se
trataría de Hijacking.
Dato importante
Los virus informáticos, pueden no ser de un único tipo, ya que en multitud de oca-
siones incluyen varias formas de actuar, pero para funcionar dependen de una acti-
vación o ejecución por parte del usuario, o bien insertar el disco en el caso de los de
boot, o ejecutar el programa que los contiene, de forma intencionada o no.
115
12.4.3 Robar información personal

Este tipo de software puede ser utilizado para robar contraseñas de sistemas o de acceso
a los sistemas bancarios, de nuestra tarjeta de crédito, etc.
En ese caso pueden hacerlo o bien infiltrándose en nuestra máquina buscando esa infor-
mación si la tenemos almacenada (por eso siempre nos recomiendan desde el banco o
cualquier otro entorno que no guardemos nuestras contraseñas en un archivo) o bien me-
diante la introducción de un programa que sea capaz de detectar las teclas que pulsamos
en un momento dado. (por este motivo muchos accesos a bancos o páginas seguras nos
pide que nuestras claves sean introducidas a través de equivalencias que van cambiando
o con ratón).
Dentro de las categorías de malware están los que tan solo pretenden gastar una broma al
usuario, que realmente no generan destrozos, sino que ponen algún mensaje en pantalla
y que lo único que ocasionan es una pérdida de tiempo, dentro de esta categoría también
podríamos introducir el Hoax, o rumores que se propagan por Internet si hacemos una
cosa o la otra.
También entraría en la categoría de software pernicioso el Spam, que genera mucho gasto
al año en las empresas su eliminación y su detección.
12.5. Software de protección

Dentro de las políticas empresariales, deberíamos tener las herramientas adecuadas para
luchar contra todos los tipos de software pernicioso vistos antes.
Dentro de este software también tendremos categorías según su especialización y lo que

nos protejan.
12.5.1 Antivirus
Es un tipo de programas ampliamente conocidos, ya que quien más quien menos si no ha
sufrido un ataque de un virus, tendrá un conocido que lo haya sufrido y que haya tenido
que luchar contra ello.
Cada vez son software más evolucionados, de igual manera que los virus y gusanos que
atacan también son cada vez más complejos. Necesitan estar actualizados, ya que lo que
nos harán será detectar posibles virus dentro de nuestros sistemas, como constantemente
están apareciendo nuevos virus lo que hace es tener una base de datos de virus conocidos
que es capaz de detectar y en la mayoría de ocasiones de eliminar, pero también trabajan
con algoritmos que le permiten detectar virus no conocidos de acuerdo a su forma de
trabajar o de actuar.
116
Existen múltiples soluciones en el mercado y deberíamos evaluar cuál es la mejor para

nuestra empresa. No es lo mismo un sistema para ordenadores que para entornos de ser-
vidores o si estamos trabajando con sistemas de virtualización, etc.
12.5.2 Firewall
La necesidad de cortafuegos en la empresa es importante, las comunicaciones con el
mundo exterior son una fuente constante de amenazas y ataques para nuestros siste-
mas, por lo que estar protegidos, impidiendo el acceso a nuestra información, bloqueando
cualquier intento de acceso al mismo tiempo que evitando que la información pueda salir
de nuestros sistemas, en caso de que algún programa quiera hacer el envío de informa-
ción a través de la red (spyware, etc.)
La instalación de este tipo de sistemas nos provocará una zona que llamaremos zona
desmilitarizada (DMZ) donde se encontrarán nuestras máquinas y donde se produce una
comunicación libre de los sistemas.
Esta zona puede ser de carácter cerrado, si lo restringimos a las máquinas que están den-
tro de nuestra sede o se podrá acceder de manera remota mediante técnicas de VPN (Red
Privada Virtual) de tal forma que tanto los puestos de trabajo como los servidores pueden
alojarse fuera de nuestra oficina y seguir estando protegidos por nuestro firewall en sus
comunicaciones con el mundo exterior.
Existen numerosos tipos de firewalls según el tipo de filtrado que realicen o donde se ins-
talen, así pueden ser para toda la red o para cada una de las máquinas.
En nuestra empresa deberíamos diseñar una política de funcionamiento para que estén
correctamente configurados.
12.5.3 Sentido común

Dentro de las políticas de seguridad de la empresa se nombrarán las reglas que nos regi-
rán para el uso y aprovechamiento de las tecnologías, pero el aplicar un poco de sentido
común nunca es un elemento sobrante.
Así, ejecutar aplicaciones de remitentes desconocidos, aplicar los parches de seguridad

de nuestros sistemas, tanto de los sistemas operativos como de nuestros servidores web
o nuestros programas de correo y por supuesto de las herramientas de seguridad como
los firewalls o antivirus.
No instalar aplicaciones perniciosas como aquellas de intercambio de archivos a través

de Internet, mantener configurados con protección nuestros navegadores para que no
ejecuten instrucciones de una página web sin permiso (VScript, ActiveX o JScript)
117
Utilizar contraseñas seguras y no siempre la misma para todos los entornos a los que
tengamos que acceder, que se renueven con cierta periodicidad.
No dejar las contraseñas escritas encima de nuestra mesa o en un post-it. No compartir

nuestras contraseñas con otros compañeros o gente externa a la empresa.
Muchas de estas recomendaciones y otras que podamos conocer suenan a entornos bási-
cos, pero se han incurrido en más de una brecha de seguridad por ellas, como en el caso
de Keirvel en Societe Generale, se valió de agujeros similares que habrían permitido a la
empresa ahorrar miles de millones de euros si todos los empleados las hubieran seguido.

Los distintos tipos de software malicioso, infeccioso, que busca beneficios, que busca
ocultarse y herramientas para protegernos de ellos.
118
13. Gestión de un ataque

“Gestionar lo que pase cuando seamos atacados dependerá de los
planes que hayamos previsto y de cómo hayamos diseñado los pla-
nes de contingencia de nuestra compañía para poder responder a
la pérdida de datos o la sustracción de información que se pueda
producir en ese entorno.”
13.1 modos de ataque

Existen multitud de métodos de atacar a las empresas, los podemos categorizar según de
dónde provengan o según cuál sea la finalidad del ataque.
13.1.1 Ataques desde el interior

El ataque a nuestros sistemas es realizado por una persona del interior de nuestra empre-
sa. Siempre podemos pensar que esto no se va a producir, que confiamos en nuestra gen-
te, pero un estudio de PriceWaterHouseCoopers The Global State of Information Security
2005 revelaba que el 33% de los ataques a los sistemas de información se producirán
desde el interior y el 28% por parte de antiguos empleados.
Por lo tanto, deberíamos preparar nuestros sistemas para un ataque desde el interior de
nuestras empresas, y prepararnos para responder a los mismos.
13.1.2 Ataques desde el exterior

Podemos pensar que no somos candidatos a ser atacados, ya que no somos un gobierno,
y eso solo pasa a los gobiernos y páginas de partidos políticos, pero aún en el caso de no
serlo, podemos ser objeto de ataques.
Según estudios realizados a directores de sistemas de 300 empresas medianas y grandes

de Estados Unidos y Reino Unido, en el año 2011, una de cada tres empresas había sido
objeto de un ataque.
119
13.1.3 Ataques a equipos físicos

Los ataques pueden ser producidos con el objetivo de entrar a un sistema para recopilar
información, que puede ser información de productos, de datos de acceso a otros siste-
mas, o a cuentas bancarias.
Se puede hacer a través de la red, incluso mediante la sustracción de información en una

casa o en la propia empresa, que entren a robar discos duros o sistemas informáticos que
tengan los datos.
13.1.4 Ataques de ingeniería social

En vez de atacar directamente una máquina pueden intentar entrar a través de engaños,
que nos impulsen a poner nuestro nombre de usuario o la contraseña de acceso a un sis-
tema en una página falsa, para luego tratar de suplantarnos en ese entorno.
Evidentemente, lo primero que pensamos es en datos bancarios, pero también podría

producirse en sistemas más aparentemente inofensivos, pero que puedan dañar nuestra
imagen, o interponerse en la relación con nuestros proveedores.
13.2. Motivación para el ataque

Dado que la mayor parte de los ataques que salen a la luz o que podemos leer en las noti-
cias suelen ser a organismos públicos, conocemos que un tipo de ataque que se da es por
cuestiones políticas.
Incluso si somos una empresa, no un organismo público, también estaremos sujetos al

riesgo de ser atacados por temas políticos, bien por ser suministradores de un gobierno
o de una empresa que haya realizado cualquier acción que pueda enfadar (el caso de la
petrolera saudí o el ataque a Twitter alegando que apoyaba una ley concreta).
Los ataques, en cualquier caso, no se tienen que limitar al ámbito político, según el es-
tudio de una consultora independiente, encargado por Corero Network Security a 300
directores de IT, muchos de los que habían sufrido ataques afirmaban que estos habían
sido producidos por fraude.
Otros de los encuestados afirmaban que los ataques habían tenido como objetivo la caída
del servicio y habían sido orquestados por su competencia.
120
Por lo tanto, no solo tenemos que tener en consideración que pudiera haber ataques de
tipo político (que nos puedan derivar incluso por la situación política del país donde es-
temos operando) sino que habrá motivaciones de tipo económico, pueden ser también
ataques movidos por venganza de un empleado descontento.
Existe también la posibilidad que los ataques sean más un entorno de diversión, reto o for-
mación, en la que un hacker esté probando sus habilidades o sus conocimientos y decida
atacar nuestra compañía, para demostrar que puede hacerlo.
13.3. el ataque
Para poder conocer qué es lo que ha pasado, y comenzar a plantearnos cómo responder, el
primer paso es saber cuál es el procedimiento seguido en el ataque.
El proceso que seguirá un ataque es, en primer lugar, la selección del objetivo, que pue-
de ser de manera específica un sistema de nuestra compañía, o simplemente puede ser
porque tengamos un tipo de aplicación que el atacante conozca o de modo aleatorio, no
siempre existe una motivación que nos ponga como objetivos del ataque, sino que este
puede ser producido contra nosotros de forma azarosa.
Para poder llevar a cabo el ataque, el atacante recopilará información sobre su objetivo, o
bien la empresa (qué sistemas tiene, información de los usuarios, de las empresas con las
que mantenemos relación, etc.)
A continuación, una vez que el objetivo está seleccionado lo que se intentará es acceder a
los sistemas, a los servidores, a la web o al entorno que se quiera atacar.
13.4. Tipos de ataque

Los tipos de ataque que se pueden dar son de diferente envergadura y calado dentro de
la empresa, la respuesta a cada uno de ellos será diferente y lo que deberíamos es ver qué
hace para plantear nuestra respuesta.
13.4.1 Denegación de Servicio

Uno de los más vistosos, así como conocidos, son los ataques de Denegación de Servicios
o DoS (Deny of Service) o DDoS (Denegación Distribuida de Servicio, en caso de querer
remarcar que se realizan desde múltiples sistemas de forma simultánea) suelen ser los
más conocidos, ya que consisten en atacar una página o un servicio web y hacerlo inac-
cesible, por lo que los sistemas visibles y conocidos de las empresas u organismos se ven
afectados por el ataque.
121
Lo que se hace realmente es en apariencia bastante simple, y es realizar peticiones de

servicio al sistema objeto del ataque, en tal número de manera simultánea que lo que se
consigue es que el sistema se sature y o bien de como resultado una bajada del rendimien-
to en el mejor de los casos, una obstrucción de tal forma que las peticiones genuinas no
llegan a buen puerto o en el peor de los casos caídas de los sistemas por saturación.
Dependiendo de lo intenso y organizado del ataque, el tiempo necesario para volver a

estar operativo puede variar.
En muchas ocasiones, este tipo de ataques tan solo buscan notoriedad o atacar la ima-
gen de la empresa caída, pues si se es capaz de vulnerar sus sistemas, muchos clientes
pueden optar por no utilizar sus servicios, o en caso de querer hacerlo no los encuentren
disponibles.
Para hacer este tipo de ataques se utilizan multitud de sistemas de forma combinada,
pueden ser o bien por la programación de sistemas para que lo hagan o por la utilización
de ordenadores que han sido infectados a tal efecto (lo conocido como redes de zombis).
13.4.2 Suplantación de identidad

Un tipo de ataques a los sistemas de las empresas que pueden causar más problemas son
los de suplantación de identidad (spoofing o fishing) que lo que harán será sustituir el
sistema o imitarlo con la intención de confundir a los usuarios.
Puede ser o bien un ataque que busque redireccionar todos los accesos a nuestros siste-
mas que se redirijan hacia sus propios sistemas, con el objeto de conseguir visitas a una
página con otras intenciones o bien acceder a un sistema que simule la página a la que
queríamos acudir, parar conseguir que el usuario, sin darse cuenta, introduzca sus claves
de acceso, consiguiendo así que los atacantes conozcan nuestras claves de acceso al sis-
tema.
El método de ataque, por lo tanto, puede darse de diferentes formas, o crear un entorno
parecido al de nuestra empresa, con la intención de suplantarlo, realizar envíos de correo
masivo, con un enlace en el que se nos solicita que cambiemos la contraseña de acceso al
sistema, o comprobemos algún valor o acceder a nuestros sistemas, sustituyendo la pági-
na web que tengamos por una que hayan creado ellos.
Otro de los modos de ataque sería sustituir la dirección IP de nuestros servidores, de tal
forma que tal y como funciona Internet, si tratamos de escribir una dirección de una pági-
na web, esta fuera sustituida por otra, y nos devuelva esa nueva dirección.
122
13.4.3 Analizadores
Una forma de ataque menos sofisticada y que en ocasiones no persigue un objetivo con-
creto, sería la de utilizar escaneadores o analizadores que busquen un tipo de programa
concreto o una versión instalada, y tratan de explotar una vulnerabilidad conocida.
En muchas ocasiones, en el momento que se detecta una vulnerabilidad de un sistema en

Internet, como podría ser un servidor de páginas web de Microsoft o un sistema Apache, o
cualquier otro servidor de aplicaciones. Muchos hackers cuya única motivación es tratar
de entrar en cualquier sitio, para demostrar o demostrarse que pueden hacerlo, intentaran
utilizar esa debilidad.
Se suele remarcar la importancia de tener los sistemas actualizados y tener la última ver-
sión de los diferentes parches de seguridad dentro de nuestros sistemas.
Esta importancia de las actualizaciones viene dada por esta posible vulnerabilidad que
encontraremos en nuestros sistemas, que, al no estar corregidas, algún intruso que sim-
plemente busque si puede acceder, detectará que podrá hacerlo y a partir de ahí lanzará
su ataque contra nuestro sistema.
13.4.4 Rastreadores
Cabe la posibilidad de poner un software que recoja paquetes de datos y los analice, estos
son los llamados rastreadores o sniffers, cuya finalidad es recoger lo que pase por un pun-
to concreto de la red, tratando de captar una contraseña u otra información útil o válida
que podamos enviar.
Por eso, es importante que las comunicaciones se realicen a través de puertos seguros y
de manera encriptada o codificada, para que así no sea posible leer la información que
enviamos dentro de los paquetes de la red.
13.4.5 Desbordamiento de Buffer

Es una forma de tomar control de una máquina mediante el envío de demasiada informa-
ción que haga que los sistemas comiencen a funcionar de manera inadecuada.
Es una característica que suele derivarse de aprovecharse de una mala programación de

un sistema dado y aprovechando esa vulnerabilidad, se realiza el ataque.
123
13.5. Repuesta
Una vez que asumimos la posibilidad de ser atacados y que en ocasiones será muy com-
plicado que de partida nosotros consigamos evitarlo, lo que deberíamos es poner los me-
dios para al menos no facilitar los ataques.
Deberíamos tener herramientas que puedan llegar a impedir que se produzcan los ata-
ques como serán Sistemas de Prevención de Intrusiones (IPS) o sistemas de defensa fren-
te a DDoS, de manera que podamos evitar que se produzcan.
Deberíamos estar con nuestros sistemas de firewall y antivirus actualizados, así como los
de los diferentes sistemas operativos y aplicaciones con los últimos parches instalados.
Es una política recomendable que el responsable de seguridad tecnológica de la empresa

esté al día de las últimas publicaciones en foros de seguridad para conocer las configura-
ciones recomendadas para evitar o prevenir ataques.
Si a pesar de todo esto se produce un ataque deberíamos tener un plan de acción.
Uno de los primeros puntos que debemos de tener en cuenta es poner en conocimiento
de las autoridades pertinentes que hemos sufrido un ataque, es posible que consideremos
que la imagen de la compañía se puede ver afectada, pero en ocasiones, el daño de imagen
es mucho mayor cuando se descubre y no lo hemos hecho nosotros.
El ataque de sistemas informáticos es un delito regulado por las diferentes legislaciones,

en el caso español, un ataque de Denegación de Servicio según el Art. 264 del código pe-
nal podría conllevar penas de cárcel de hasta 3 años.
El ataque incluso puede haber sido perpetrado desde el interior de nuestra compañía, por
uno de los empleados, por lo que nuevamente lo primero sería hacer público que este se
ha producido notificándolo a las autoridades.
De igual forma, si somos conscientes que alguien de nuestra empresa o desde nuestra
empresa está utilizando nuestros recursos para realizar un ataque contra otros sistemas,
deberíamos responder de forma correcta y coordinada.
En ocasiones, el ataque puede tener intenciones ocultas salvo que realicemos un análisis
forense completo de los sistemas no detectaremos (podría haberse utilizado para introdu-
cir software en nuestros sistemas para luego utilizarlos o un virus que implique la perdida
de información posterior o que nosotros estaremos propagando a través de la red).
124
Deberíamos medir el alcance del ataque, actuar con rapidez y aislar el mismo. Tener un
plan de contingencia de tal forma que podamos seguir trabajando o al menos la afecta-
ción de los sistemas sea la menor posible (herramientas de back-up o sistemas alternati-
vos configurados).
Si en el momento de reaccionar frente al ataque establecemos o tenemos una política

demostrable de seguridad, podremos evitar futuros problemas legales o minimizarlos.

Los diferentes tipos de ataque, según su intencionalidad y procedencia y qué debemos

hacer en caso de ser atacados para protegernos.
Dato importante
Los ataques pueden ser producidos con el objetivo de entrar a un sistema para re-
copilar información, que puede ser información de productos, de datos de acceso
a otros sistemas, o a cuentas bancarias. Se puede hacer a través de la red, incluso
mediante la sustracción de información en una casa o en la propia empresa, que
entren a robar discos duros o sistemas informáticos que tengan los datos.
125
14. El factor humano

“Cuanto más automaticemos los controles, más conseguiremos eli-
minar el factor humano de los posibles errores que podamos come-
ter con la gestión de los mismos, por ello es interesante tener he-
rramientas que permitan las comprobaciones en los sistemas, para
evitar errores que nos permitan pasar por encima de las políticas.”
14.1. Errores humanos

En ocasiones, podemos plantear que ciertas actitudes son mal vistas o mal planteadas y
tenemos la tendencia de culpar o criticar a los usuarios por incumplir las políticas, pero la
realidad es que es una actitud natural por parte de las personas.
Así, deberíamos primero tener en cuenta que muchas de las grietas de seguridad que se
producen son por fallos sin mala intención dentro del normal funcionamiento del día a
día.
Por ejemplo, ¿quién no se ha equivocado al introducir un valor en un formulario? o ¿quién

no ha eliminado un archivo por error?
Errores simples son comunes y no suponen mayor problema, tenemos que aceptarlos
como inevitables y hacer lo mejor para detectarlos y corregirlos antes de que sea dema-
siado tarde.
En el contexto de seguridad informática, pequeños errores de configuración pueden dejar

puertos abiertos o sistemas vulnerables y desprotegidos.
Realmente los errores humanos son más probables y es más fácil que causen violaciones
de seguridad que vulnerabilidades técnicas en los sistemas.
14.2. Objetivos
Siempre lo dicen los analistas de seguridad, pero generalmente no se suele hacer dema-
siado caso en las empresas, el mayor riesgo para los sistemas de información se encuentra
dentro de la empresa.
Esto no es algo nuevo, Genghis Khan enunció refiriéndose a la gran muralla y a su teórica
invulnerabilidad y defensa que: la eficacia de una muralla no depende de su altura o lon-
gitud, sino del valor de los soldados que la guardan.
126
De similar forma y refiriéndose a los sistemas informáticos en su libro Secretos y mentiras

del año 2000 que: la seguridad es solo tan buena como el más débil de los eslabones, y las
personas son el eslabón más débil de la cadena.
Incluso se han realizado estudios que lo demuestran: en edificios protegidos con tarjetas
de acceso, el 56% de los empleados había podido acceder al interior del edificio en alguna
ocasión sin llevar la tarjeta y casi el 85% de ellos había facilitado el acceso al mismo a per-
sonas que no conocía en absoluto.
A este factor le podemos sumar la alta rotación de personal que se suele dar en las em-
presas, donde los empleados no suelen estar de por vida, sino que se van produciendo
movimientos de las personas entre distintas empresas, por becas, subcontrataciones, as-
censos, o simples despidos y nuevas creaciones de puestos de trabajo, y que muchas de
las personas que pasaron por las empresas siguen conservando información que ya no
necesitan, o peor aún, tienen acceso a la información de la empresa.
Al final, uno de los mayores riesgos se haya en que la información y la seguridad de acce-
so a la misma está gestionada por personas y como tal debemos entender que esto puede
llegar a provocar el incumplimiento de normas dentro de la empresa.
Viendo esto, desde diversas consultoras recomiendan establecer políticas que centradas
en garantizar la seguridad de la información y en realizar el constante seguimiento de las
conductas del usuario.
14.3. Movilidad humana

Uno de los factores que introducen riesgo en las empresas es el hecho de la movilidad,
poder conectarse de manera remota desde casa o bien desde localizaciones remotas.
A la hora de poder establecer esta conectividad en remoto deberíamos tener cuidado no

solo de permitir conexión con los sistemas de la empresa sino establecer limitaciones de
quién se puede conectar y a qué entornos.
En muchas ocasiones, los accesos se pueden estar realizando a través de wifi publicas
en cafeterías, hoteles o aeropuertos, en otras ocasiones se podrá acceder al correo elec-
trónico a través de plataforma de web-mail y estar utilizando ordenadores de terceros o
diferentes emplazamientos.
Tendremos que tener en cuenta al establecer la protección y seguridad de este tipo de

comunicaciones este tipo de casuísticas, pues si bien nosotros podemos dar indicaciones
a los usuarios para que no lo hagan, el problema puede ser que no nos hagan caso.
127
Tenemos otra casuística como es el poder llevarnos información de la empresa con dispo-
sitivos cada vez más sencillos como pueden ser dispositivos de almacenamiento USB o
incluso a través de nuestro teléfono móvil.
En ocasiones, surge la tentación de prohibir estas prácticas y evitar que los usuarios se
lleven la información a través de cualquier dispositivo, pero eso simplemente nos com-
plica la operatividad de la empresa, a cambio lo que deberíamos es establecer políticas
que permitan que este paso de información se haga de forma codificada y encriptada en
aquellos casos que sea necesario, para así evitar que se pueda establecer formas alterna-
tivas de sacar la información.
Asimismo, también deberíamos establecer seguridad para cada uno de los empleados de
tal forma que se autentifique dentro de los sistemas con su propio usuario y clave.
La política de establecimiento de clave es otra de esas políticas en las que habitualmente

entra en conflicto el establecimiento de la seguridad por parte de la empresa y la comodi-
dad de los usuarios, que no quieren tener que recordar multitud de diferentes contraseñas.
Trataremos de establecer entornos en el que la seguridad sea fuerte, con contraseñas

seguras, pero que al mismo tiempo pueda facilitar la comunicación entre las distintas
aplicaciones, poder establecer sistemas que, con intercambio de certificados y facilida-
des similares, el usuario no deba de estar constantemente autentificándose dentro del
entorno una única vez y permaneciendo conectados desde ese momento y accediendo a
los diferentes entornos.
A cambio de este tipo de facilidades deberíamos intercambiar con los usuarios que ellos
no dejen sus contraseñas a compañeros y mucho menos a personas de fuera de la empre-
sa, para evitar problemas dentro del entorno.
Deberíamos tener cuidado si realizamos este tipo de políticas de seguridad. Tenemos que
tener completamente actualizada la lista de empleados, de tal forma que mantengamos al
día las altas y las bajas de personas y los permisos asociados a cada uno de ellos.
Si tenemos un entorno con una cierta rotación, personas que se puedan haber ido recien-
temente de la empresa en malas condiciones pueden sufrir la tentación de sacar informa-
ción y distribuirla con la competencia o para borrar datos importantes en un “ataque de
furia”.
128
14.4. Ejemplo de políticas

Podremos establecer una política a través de una circular en la que deberíamos establecer
las normas de obligado cumplimiento a los empleados, pero esta circular tendrá que ir fir-
mada por una persona de la dirección para que tenga mayor calado y las políticas deberán
de haber sido consensuados con la dirección.
El objeto de la presente circular es la difusión de las funciones y obligaciones del personal

de la compañía, en materia de seguridad de datos personales. Asimismo, constituye el
objeto de dicho documento circular un resumen de los aspectos más relevantes de la polí-
tica de deber de secreto y confidencialidad de la información implantados por la empresa:
La normativa de seguridad plasmada en el DOCUMENTO DE SEGURIDAD es de obliga-

do cumplimiento para todo el personal con acceso a los datos automatizados de carácter
personal y a los sistemas de información.
A continuación, se presenta un resumen de los aspectos más relevantes de la normativa

de seguridad que deben cumplir los empleados de la compañía; así como un extracto de
las políticas de deber de secreto y confidencialidad de la información implantadas por la
empresa.
1. Con relación a las contraseñas se habrán de observar las siguientes normas:
• La longitud mínima de la contraseña será de 8 caracteres.
• La contraseña de acceso caducará a los 60 días, debiendo ser modificada en el

momento de realizar el primer acceso al sistema.
• Se evitarán nombres comunes, números de matriculas de vehículos, teléfonos,

nombres de familiares, amigos, etc. y derivados del nombre de usuario como
permutaciones o cambio de orden de las letras, transposiciones, repeticiones de
un único carácter, etc.
• Los usuarios serán responsables de su salvaguarda y custodia.
129
1. Cualquier soporte recibido deberá ser registrado, siguiendo el procedimiento esta-

blecido en el DOCUMENTO DE SEGURIDAD. Una vez procesado, el soporte reci-
bido deberá ser borrado completamente. En el caso de que por un motivo justificado
se desee conservar el soporte recibido, deberá inventariarse, siguiendo las normas
descritas en el DOCUMENTO DE SEGURIDAD. Para conocer dicho procedimiento,
deberá ponerse en contacto con el Responsable de Protección de Datos.
2. La salida de soportes y ordenadores personales fuera de la organización precisa de

autorización. En el DOCUMENTO DE SEGURIDAD se describen el procedimiento
para obtenerla. Para conocer dicho procedimiento, deberá ponerse en contacto con el
Responsable de Protección de Datos.
3. Toda incidencia en materia de seguridad deberá comunicarse al Departamento de

Sistemas de Información por escrito.
4. Todos los ficheros temporales que los usuarios mantengan en sus ordenadores per-
sonales deberán ser borrados, una vez haya finalizado la finalidad para la que fueron
creados.
5. Queda terminantemente prohibido la creación de nuevos ficheros que supongan el

tratamiento de datos personales, así como la cesión de los mismos sin previa autori-
zación del Responsable de Protección de Datos.
6. No está permitido instalar “de motu propio” ningún producto informático en el siste-
ma de. Todas aquellas aplicaciones necesarias para el desempeño de su trabajo serán
instaladas únicamente por personal del Departamento de Sistemas de Información.
7. Queda prohibido utilizar los recursos del sistema de información a los que tenga ac-
ceso para uso privado o para cualquier otra finalidad diferente de las estrictamente
laborales.
8. Bajo ningún concepto puede revelarse a persona alguna ajena a la empresa informa-
ción, a la que haya tenido acceso en el desempeño de sus funciones, sin la debida
autorización.
9. Queda terminante prohibido facilitar a persona alguna ajena a la compañía ningún

soporte conteniendo datos, a los que haya tenido acceso en el desempeño de sus fun-
ciones, sin la debida autorización.
130
10. No está permitido utilizar la información referida en el apartado anterior únicamente

en la forma exigida por el desempeño de sus funciones y no disponer de ella de nin-
guna otra forma o para otra finalidad diferente.
11. Queda terminantemente prohibido utilizar ninguna información que hubiese podido
obtener por su condición de empleado y que no sea necesario para el desempeño de
sus funciones.
Los compromisos anteriores deben mantenerse, incluso después de extinguida la relación

laboral con la empresa.
Asimismo, se recuerda que el trabajador será responsable frente a la compañía y frente a

terceros de cualquier daño que pudiera derivarse para unos u otros del incumplimiento
de los compromisos anteriores y resarcirá a la empresa las indemnizaciones, sanciones o
reclamaciones que ésta se vea obligada a satisfacer como consecuencia de dicho incum-
plimiento.
Una vez enviada la circular firmada, será interesante establecer una política que nos per-
mita comprobar la recepción de la misma por todos los empleados y su conocimiento o
comprensión de las mismas.
Una de las políticas que algunas empresas implementan es el prohibir a los empleados el
acceso a ciertos sitios web, como redes sociales, prensa, etc. Se pretende con ello eliminar
también el acceso a paginas potencialmente seguras, que puedan contener malware en
su interior, al mismo tiempo que se consigue eliminar elementos de distracción para los
empleados de la compañía.
Este tipo de políticas en ocasiones pueden ser contraproducentes, ya que los empleados,
hoy en día con la proliferación de smartphones y demás dispositivos, podrán acceder a las
redes sociales y a este tipo de páginas que intentaremos prohibir, por lo que la verdadera
motivación, actualmente, para prohibirlas quedará desde el punto de vista de la seguri-
dad, lo cual no es un elemento desdeñable.
Dato importante
Comprobar que las contraseñas sean fuertes o que se actualicen con la frecuencia
adecuada son opciones que nos va a poder revisar el software de forma automática.
131
14.5. Establecer auditorías

Para poder garantizar el cumplimiento de las diferentes normativas y directivas de segu-
ridad que hayamos establecido en la empresa será interesante poder analizar y evaluar su
cumplimiento por los distintos empleados.
Para ello, se podrán establecer auditorías de cumplimiento en las que analicemos que
realmente los datos y las políticas que hayamos establecido se estén cumpliendo de forma
correcta.
Comprobar que las contraseñas sean fuertes o que se actualicen con la frecuencia adecua-
da son opciones que nos va a poder revisar el software de forma automática, por lo tanto,
deberíamos preocuparnos por el cumplimiento de otras normativas, como aquellas que
hayamos dado en circulares que las herramientas no nos permitan comprobar de forma
automática.
Cuanto más automaticemos los controles, más conseguiremos eliminar el factor humano
de los posibles errores que podamos cometer con la gestión de los mismos, por ello es
interesante tener herramientas que permitan las comprobaciones dentro de los sistemas,
para evitar errores y tentaciones que nos permitan pasar por encima de las políticas.
Las auditorías de seguridad se deben de llevar a cabo sin previo aviso, del mismo modo
que las auditorías de riesgos laborales y cualquier otro tipo de auditorías en las que lo in-
teresante es observar el correcto cumplimiento de las normativas, en entornos bajo aviso
esto no siempre se puede observar, ya que los empleados no actuarán de forma natural,
sino que tenderán a realizar una mayor observación de las mismas en esas circunstancias.
Para poder realizar las auditorías de forma correcta deberíamos realizar un inventario de
los puntos a comprobar, establecer test de cumplimiento y comprobaciones de que se está
funcionando de manera correcta.
Podremos observar la actividad de los empleados, para ver que no incumplen ninguna
de las directrices dadas por la dirección. Podremos comprobar los servidores proxy de la
compañía el tipo de sitios que se visitan o podemos realizar comprobaciones de cumpli-
miento de otras políticas.

Cómo los diferentes factores humanos son uno de los mayores riesgos en las empresas,
no conseguiremos eliminar el riesgo, pero al menos trataremos de minimizarlo y convivir
con él.
132
15. Caso práctico: Sony Networks

“Cuando se produce un ataque puede haber múltiples intenciones.
Si el ataque es por esta motivación política, quedará revelado, y
nuestros intentos de silenciarlo pueden ocasionar darle más rele-
vancia. Si la motivación del ataque es económica, lo mejor es decla-
rar ese ataque para que los entornos implicados puedan reaccionar
y protegerse de la forma más adecuada posible.”
15.1. Introducción al caso

En mayo del 2011 los responsables de la empresa Sony Corporation Kazuo Hirai (CEO
de Sony Corporation) Shinji Hasejima (CIO de Sony Corporation) y Shiro Kambe (VP y
responsable de comunicaciones de Sony Corporation) dieron una rueda de prensa en la
que reconocían que durante el mes anterior habían sido objeto de un ataque informático
en la red de PlayStation Network.
Sony estaba reconociendo con este acto que había sido objeto de un ataque, según las
informaciones que salieron posteriormente, el día 19 de abril detectaron actividad inusual
en sus sistemas, que les llevaron a descubrir la existencia de una intrusión en los mismos
que había estado sucediendo entre el día 17 y el mismo 19 de abril.
El ataque se había perpetrado contra la red de PlayStation Network, donde los usuarios de
la popular consola se conectaban para poder jugar a través de la red y descargar juegos o
actualizaciones.
Sony contrató a tres empresas de seguridad informática para que analizaran el caso y
solicitó al FBI (Oficina Federal de Investigación de Estados Unidos) que abriera una in-
vestigación criminal sobre el mismo.
Finalmente, tuvo que cambiar completamente la red, indemnizar usuarios y el golpe a su

imagen le sirvió para perder el primer puesto en la venta de consolas a manos de Micro-
soft.
133
15.2. Cronología de un ataque

El 17 de abril se produce un ataque a los sistemas de Sony aprovechando un agujero en su
seguridad provocado por la no actualización de un parche crítico.
El atacante usando una vulnerabilidad conocida (ya había sido atacado antes y publicado
el ataque) se introdujo en los sistemas de Sony Online Entertainment.
Una vez dentro, el asaltante cogió datos almacenados en las Bases de Datos de usuarios
del sistema que incluían elementos como nombres de usuarios, contraseñas y otros datos.
La forma de acceder fue conectarse al sistema que tenía la siguiente configuración:
Figura 1. Configuración del sistema.
Fuente: http://www.spiegel.de/netzwelt/games/sicherheitsrisiko-hacker-konnten-daten-von-100-millionen-sony-kunden-kopie-
ren-a-759830.html
134
Un servidor de bases de datos, donde se almacenaba la información, que era consultada

por un servidor de aplicaciones con el que se comunicaba a través de un cortafuegos, y
que era publicada por un servidor web, que a su vez comunicaba con el servidor de aplica-
ciones a través de un firewall y que establecía otro firewall para sus comunicaciones con
el mundo exterior.
Una configuración en principio con cierta protección para evitar la pérdida de informa-
ción y poder detener a los intrusos.
Figura 2. Ruta de intrusión.

Fuente: http://www.spiegel.de/fotostrecke/sony-so-kamen-hacker-an-kundendaten-fotostrecke-67530-2.html
Lo que hizo el intruso fue inyectar un código en el servidor de aplicaciones a través de

una vulnerabilidad conocida que le permitía funcionar a modo de enlace de las comuni-
caciones internas dentro de la red.
Una vez conseguido ese acceso, se hizo pasar por este servidor de aplicaciones para ata-
car a la base de datos y a partir de ese momento, tratar de recopilar toda la información
que quisiese. Las posteriores pesquisas forenses se encaminaron en tratar de detectar
qué se había mirado en la base de datos, qué datos habían salido de la empresa y cómo se
había realizado este ataque. Incluyendo si era posible identificar al atacante, hecho que
hasta el momento no se había producido.
135
Figuras 3 y 4. Ruta de intrusión.
Fuente: http://www.spiegel.de/fotostrecke/sony-so-kamen-hacker-an-kundendaten-fotostrecke-67530-3.html
136
El sistema tenía una seguridad definida pero el atacante conocía vulnerabilidades del
mismo, se aprovechó de ellas y lanzó su ataque para conseguir robar datos de los sistemas
de Sony.
El problema dentro de este ataque, no es que se produjera sino todo lo que sucedió a con-
tinuación, que le dio más repercusión y más notoriedad al mismo.
15.3. Respuesta de Sony

El día 19 de abril, desde Sony se detecta un acceso y unas transacciones extrañas dentro
del sistema, con lo que comienzan a analizar que puede estar pasando.
Como consecuencia de esa detección y análisis, cierran la red de PlayStation Network,

provocando una caída del servicio a muchos usuarios. No era la primera vez que el servi-
cio se caía, pero normalmente era una cuestión que en poco tiempo volvía a estar dispo-
nible.
Tras dos días sin funcionar, aparece un mensaje de que la red estaba experimentando
problemas, que en breves momentos estaría de nuevo operativa y que esta se encontraba
en mantenimiento.
Sin embargo, la red no vuelve a operar con normalidad en ningún momento y eso empie-
za a disparar los rumores de que algo estaba pasando.
Acentuado por un ataque previo a principios de año por una conocida red de hackers
activistas denominada “Anonymous” los rumores de que puede haberse producido un
ataque aumentan.
15.3.1 Primer comunicado

Tras una semana con los sistemas caídos, desde Sony reconocen que la red se encontraba
caída debido a un ataque que habían recibido en sus sistemas.
Sony indicó que estaban trabajando para solucionar los problemas ocasionados, así como
para evitar futuros problemas, por el momento la red se quedaría caída hasta que pudie-
sen garantizar que todo iba a funcionar correctamente.
137
15.3.2 Segundo comunicado

Dos días más tarde, nueve días después de detectada la intrusión, Sony anuncia que han
detectado que con la intrusión pueden haberse perdido datos.
El ataque es considerado como un acto criminal y como tal solicitan la intervención de las
autoridades, reconociendo que datos de usuarios se pueden haber visto comprometidos,
ya que no se encontraban almacenados de forma codificada alguna, aunque si detrás de
un sofisticado sistema de seguridad.
Sony cuenta con firmas de seguridad privada, así como con la ayuda del FBI para tratar de
esclarecer la magnitud y el origen del ataque.
Entre los datos perdidos de los usuarios, se pueden incluir algunos datos de carácter per-
sonal, pero en ningún caso datos de tarjetas de crédito de los usuarios.
15.3.3 Rueda de prensa

El dos de mayo, dos semanas después de comenzar el ataque se produce la rueda de pren-
sa por parte de los dirigentes de Sony en el que confirman que se produce un ataque a los
sistemas y que se ha producido el robo de datos de usuario.
Tras más de tres cuartos de hora de rueda de prensa y como respuesta a una pregunta,
el CEO de SONY reconoce que las contraseñas de acceso de los usuarios no estaban en-
criptadas.
Pocos minutos después, el CIO de la compañía matiza esta respuesta al decir que, si bien
las contraseñas no eran almacenadas de manera encriptada, sí que habían sido almacena-
das con un algoritmo y no se encontraban en texto plano.
Unos días más tarde, continúan avanzando los resultados de los análisis forenses y detec-
tan que además de la pérdida de datos de usuario, podría haber más datos dentro.
Asimismo, reconocen que entre los datos robados es posible que se encuentren los datos
de tarjetas de crédito de los usuarios. Que igual que el resto de datos, estos estarían alma-
cenados sin una encriptación especifica, ya que era un archivo de texto.
138
15.4. Consecuencias
Tras el ataque, Sony Online Network permaneció cerrado durante varias semanas, provo-
cando una gran pérdida de confianza por parte de los usuarios, así como la pérdida directa
del negocio generado por la red.
En el intento de recuperar a los usuarios e incentivarlos a volver, comenzó una estrategia

de marketing que incluía periodos gratuitos para ciertos juegos y habilidades, así como
un juego de regalo para los usuarios que regresasen a la red.
Se estima que se perdieron los datos de más de 100 millones de usuarios con datos perso-
nales, así como contraseñas (que podrían ser las mismas de otros sistemas online).
Se perdieron los datos de aproximadamente doce millones de usuarios de tarjetas de cré-

dito, que debieron de ser repuestas por parte de las compañías de tarjetas para evitar
futuros fraudes.
Las pérdidas económicas derivadas del ataque no son fácilmente calculables, ya que coin-
cidieron en el tiempo con el terremoto que provocó un Tsunami en Japón, entre ambos
acontecimientos ayudaron a precipitar la caída de las ventas de Sony y provocaron ese
trimestre unas pérdidas de cerca de 200 millones de dólares.
La realidad es que la demanda de consolas bajó y aunque los usuarios acabaron retor-
nando a la red de PlayStation Network, el daño para la imagen hizo que los usuarios se
decantasen en mayor medida por otras opciones.
Asimismo, se estableció una comisión de investigación en el Congreso de Estados Uni-

dos, ya que la empresa que gestionaba la red, Sony Online Network, era una empresa
americana, para determinar las responsabilidades derivadas del ataque.
15.5. ¿Qué se podria haber hecho diferente?

En el ataque a Sony quedaron reveladas ciertas actuaciones que no estaban de acuerdo
con los mejores estándares que existían en la industria y que siendo una compañía tan
representativa y manejando información de tipo tan importante y deberían de haberse
observado.
La red de Sony se encontraba protegida y se había realizado un diseño en el que existían

múltiples cortafuegos que pretendían evitar el acceso a personal no autorizado.
Inclusive con una configuración muy protegida, cualquier entorno es susceptible de ser
atacado, ya que una malla de protección se encuentra conformada por un conjunto de
puntos y uno de ellos puede ser menos seguro que cualquier otro y por ahí caería el sis-
tema.
139
La red de Sony Online Network había sido atacada meses antes por un grupo de cyber-
activistas, en protesta contra la demanda que Sony estaba realizando contra una persona
en San Francisco (California). Por lo que era conocido que la red tenía puntos débiles y
era susceptible de ser atacada.
A pesar de este ataque no se tomaron las medidas necesarias para proteger la información
que se encontraba en sus sistemas, las contraseñas no eran tratadas de forma encriptada,
sino que se trataban como un texto plano y solo se codificaban a la hora de guardarlas, lo
que facilitaba el acceso.
Por otro lado, tenían guardada información de los usuarios de forma abierta y combinada
con información sensible como eran los datos de las tarjetas de crédito.
En el momento de ser detectado el ataque, se dijo que se estaba procediendo a una actua-
lización del sistema y no se comenzó a notificar las posibles consecuencias, hasta varios
días después no se comunicó que había un ataque y que este podía incluir la pérdida de
datos.
Aun así, se tardó más tiempo en reconocer la existencia de datos de tarjetas de crédito
entre los posibles datos robados.
La demora en advertir la pérdida, así como en reconocer el posible alcance, dio lugar a
que las pesquisas se complicasen y a que los asaltantes a la red pudieran haber actuado
de manera fraudulenta con los datos robados.
No ha aparecido un gran número de demandas posteriores, aun así, sí que durante varios
días Sony estuvo dando explicaciones, con nuevos datos en cada ocasión del alcance de
la incursión y la cantidad y tipo de datos que fueron robados del ataque.
Si desde el primer momento Sony hubiera reconocido ante las autoridades que había
habido un ataque y se hubiera puesto a colaborar con ellas en el esclarecimiento, es pro-
bable que la bola de nieve generado por ello no hubiera obligado a una rueda de prensa
de los directivos de más alto nivel.
Al ir ampliando con cuentagotas la información disponible, se daba pie a especulaciones

y se colaboraba con la pérdida de confianza en la compañía, ya que los usuarios entien-
den que se puede haber producido un ataque, que se puede haber vulnerado la seguridad
(Hollywood se ha encargado de que todos veamos como por muy protegido y seguro que
sea un entorno, informático o físico, asumamos que una persona preparada y con la moti-
vación adecuada puede entrar en los sistemas y atacarlos).
Al negar primero el ataque, posteriormente la pérdida de datos y a continuación que no

había habido perdida de datos financieros, para al final acabar reconociendo todo, lo que
conseguía Sony era ponerse en entredicho a sí misma.
140
De haber existido una política clara de respuesta pre organizada al ataque, no previendo
la magnitud del ataque, pero sí estableciendo el orden de actuación, la respuesta de Sony
al ataque podría haber sido más clara y menos perjudicial para su imagen.
En ocasiones, hablamos de la cultura de la compañía como factor decisivo en ciertas ac-

titudes o respuestas y en este caso, Sony es una corporación que pasa por ser hermética,
cerrada de acuerdo a la información que comparten y con un método de actuación que no
incluye generalmente comunicaciones de cada medida o paso a tomar.
En situaciones como la presente puede resultar un inconveniente dado que la transparen-

cia como respuesta a un ataque acostumbra a ser la mejor solución.
Cuando se produce un ataque puede haber múltiples intenciones, como la política (quedó
reflejada en el primer ataque que sufrió la red) que lo que busca es visibilidad, en ocasio-
nes nos podemos sentir tentados de ocultar la existencia del incidente con la impresión
de que así se reduce el daño, sin embargo, si desde el primer momento somos nosotros
quienes declaramos el ataque podemos restarle importancia. Si el ataque es por esta mo-
tivación política, quedará revelado, y nuestros intentos de silenciarlo pueden ocasionar
darle más relevancia.
Si, por el contrario, la motivación del ataque es económica, bien por la sustracción de in-
formación valiosa de forma directa, bien por el acceso a elementos valiosos, lo mejor que
podemos hacer es declarar ese ataque para que los entornos implicados (compañías de
seguros, compañías de tarjetas de crédito, entidades bancarias, etc.) puedan reaccionar y
protegerse de la forma más adecuada posible.
En cualquiera de las situaciones, el tratar de ocultar el ataque para salvaguardar la imagen

de la empresa puede ser contraproducente, además del hecho que implica que el ataque
es un acto criminal, legislado por los códigos penales de la mayoría de los países, por lo
que la pronta puesta del hecho en conocimiento de las autoridades puede ayudar a escla-
recerlo y a atrapar a los culpables en caso de ser posible.
El caso de Sony Online Network es uno de los mayores casos de pérdida de información
en Internet, sin embargo, no es el único, muchas otras redes, empresas, organismos públi-
cos han sido atacados en mayor o menor medida, quedando expuesta información de sus
usuarios, datos bancarios, de la Seguridad Social, o simplemente con caídas del servicio
ofrecido por estas compañías.
141
Reconocer pronto los hechos ayuda a que las actividades sean atajadas lo más rápido po-
sible y evita que se vaya incrementando la magnitud del ataque debido a la ausencia de
información, que es una de las motivaciones en Internet por la cual los foros se disparan.
Si de partida damos toda la información, no damos lugar a la opinión y se evita el debate

sobre qué puede estar pasando. Si por el contrario no damos información, las especulacio-
nes pueden alcanzar grandes dimensiones y ayudar a que el hecho se magnifique.

En esta unidad didáctica hemos podido ver:
Qué sucedió en el ataque a SONY Networks y qué se podría haber hecho para contestar
de mejor manera.
Dato importante
De haber existido una política clara de respuesta pre organizada al ataque, no

previendo la magnitud del ataque, pero sí estableciendo el orden de actuación, la
respuesta de Sony al ataque podría haber sido más clara y menos perjudicial para
su imagen.
142
16. Seguridad y privacidad

“En la gestión de la privacidad y de las aplicaciones con las que
compartimos información, es importante conocer con quién y cuán-
ta información compartimos, cada vez podemos controlarlo mejor
gracias a las presiones de los diferentes grupos de usuarios y go-
biernos para controlar ese tráfico de información.”
16.1. Big Data

En Internet, contra la creencia popular, las personas no son anónimas, no solo en aquellos
sitios como redes sociales donde nos identifiquemos con nuestro nombre o usuario, sino
que directamente por el mero hecho de navegar por distintas páginas web vamos dejando
un pequeño rastro que nos identifica, dado que en muchas ocasiones estas páginas utili-
zan cookies (pequeños documentos que permiten conocer el perfil del usuario de la pá-
gina aunque no tienen porqué recoger información personal) u otras herramientas útiles
para conocer a los usuarios y ofrecerles los mejores servicios posibles.
Existen múltiples opciones para conocer que estamos haciendo así si por ejemplo vemos
un estudio de una consultora que dice que el 70% de los usuarios ha buscado información
sobre un asunto en cuestión, por ejemplo, deportes o cualquier otro dato, es porque los
registros de las acciones realizadas se quedan almacenados.
Internet es una fuente que genera datos de manera constante, todas nuestras actividades
en la red quedan registradas y almacenadas y posteriormente pueden ser tratadas.
Actualmente, existe una tendencia que es lo que se conoce como Big Data, que consiste
en el manejo de información para obtener conclusiones.
En el mundo del Big Data la idea no es tanto el control del dato unitario como tal, sino
grandes volúmenes de información que serán tratados para conseguir tendencias, o con-
seguir predecir hechos. Son entornos utilizados lo mismo para la gestión de datos climá-
ticos que para el análisis por parte de las fuerzas de seguridad de ingentes cantidades de
datos.
Pero las empresas en entornos de publicidad, aprovechan grandes cantidades de datos

para conocer y segmentar a la población y así poder realizar campañas de publicidad lo
más ajustadas a los usuarios, conociendo los gustos de la población.
143
16.2. Cookies
Las cookies son unos pequeños documentos que permiten conocer el perfil del usuario de
la página, aunque no tienen porqué recoger información personal, que permiten facilitar
cosas como bienvenidas personalizadas, ultima vez de visita de la página, personalización
de acceso a cuentas de correo sin necesidad de tener que loguearse, propuesta de links
por búsqueda (por ejemplo, en Google), carritos de compra, etc.
Estas prácticas se intentan regular para evitar el abuso que lleve a prácticamente llegar
a conocer a una persona, dado que en ocasiones se puede tener demasiada información
sobre ella.
Entre la información que se puede almacenar se incluye desde donde estamos navegando
(ubicación geográfica aproximada, determinada por la dirección que tendrá el terminal
desde el que estemos accediendo a la página) con qué navegador estamos accediendo, in-
cluso la información del sistema operativo desde el que accedemos, cuántas veces hemos
accedido a esa página e incluso desde dónde hemos llegado a esa página.
Esta información, que en principio se generó para facilitar la compra online y poder alma-
cenar información mientras recorríamos una tienda a modo de cesta de la compra para
luego tener todos los componentes y realizar una única compra, es también utilizada para
otros fines.
En ocasiones, nos preguntamos cómo puede ser que las páginas web nos ofrezcan publi-
cidad que más o menos se ajustan a nuestros intereses, las cookies son en muchas ocasio-
nes las responsables de que los sistemas sepan cuáles son nuestros intereses y de acuerdo
a ello nos ofrezcan información interesante para nosotros.
Estas herramientas, si bien son entornos útiles para los programadores de páginas web,
ya que les permiten facilitar la navegación a las personas que quieran acceder y ofrecer
información más ajustada a los intereses de los usuarios, también son entornos que pue-
den atacar la privacidad de las personas que accedan a los sistemas, además de no ser
entornos 100% fiables.
La utilización de esta información es, por ejemplo, la base de servicios tan populares y
útiles para el Internet de hoy en día como Google AdSense y Google Adwords, herramien-
tas que rigen la mayor parte de la publicidad que vemos cuando navegamos por Internet.
Estas herramientas también son las que utilizan los sistemas para mantener abierta una
sesión sin obligarnos a conectarnos y validarnos constantemente a los sistemas, son por
lo tanto herramientas útiles y que nos interesa mantener.
144
Para evitar el mal uso de las mismas, las autoridades han establecido regulaciones que
permitan protegernos contra usos no autorizados, así han ido saliendo leyes que obliguen
a indicar a los usuarios de las páginas web si se va a realizar el uso de cookies, incluso
permitiendo desactivarlas.
16.3. Privacidad
Según la RAE, la privacidad es: ámbito de la vida privada que se tiene derecho a proteger
de cualquier intromisión.
Hay otras definiciones más completas, como la de Alan Westin en su libro de Privacy and
Freedom, 1967: es el derecho de los individuos, grupos o instituciones para determinar
por sí mismos cuándo, cómo y hasta qué punto la información sobre ellos se comunica a
los demás.
Dada esta segunda definición, tenemos que tener en cuenta que la privacidad en sí no es
un valor exacto, de hecho, existen múltiples juicios que involucran a personalidades con
ataques contra su intimidad y su privacidad, por revelar más información de la que ellos
desean y que se haya obtenido sin su consentimiento.
Según el mismo libro de Alan Westin, Privacy and Freedom, 1967: cada individuo está
continuamente en un proceso de ajuste personal en el que equilibra el deseo de privaci-
dad con el deseo de divulgación y comunicación.
Las discusiones sobre la privacidad no son algo nuevo, la diferencia es que con Internet
se han multiplicado los riesgos a la privacidad, se ha abierto un nuevo entorno de comu-
nicación, donde muchas veces no somos conscientes de la gestión de la información, de
los rastros que dejamos y de los datos que ofrecemos libremente.
Por esto, las autoridades están viendo las posibles amenazas a la privacidad y han de
ponerse manos a la obra para legislar y para ayudarnos en la tarea de mantener nuestro
derecho a la protección de nuestra información.
Dato importante
Las cookies, si bien son entornos útiles para los programadores de páginas web, ya
que les permiten facilitar la navegación a las personas que quieran acceder y ofre-
cer información más ajustada a los intereses de los usuarios, también son entornos
que pueden atacar la privacidad de las personas que accedan a los sistemas, ade-
más de no ser entornos 100% fiables.
145
16.4. Ejemplo de evolución de privacidad: Facebook

Con la llegada de las redes sociales el debate se hace más grande, en la misma proporción
en la que se disparan los riesgos, así por ejemplo Facebook, claro líder del mercado de las
redes sociales, ha ido evolucionando en su política y en su gestión de la privacidad de
acuerdo a las presiones de los usuarios.
Facebook es una red social creada en 2004, aunque no es hasta unos años más tarde cuan-
do termina de despegar, la red social en principio era para el contacto y comunicación
entre estudiantes de una universidad de Harvard, por lo que la información que se com-
partía era mayormente entre conocidos, o al menos compañeros de universidad, rápida-
mente fue creciendo, incrementando el número de universidades, hasta que en 2006 se
hace abierta y se dispara el número de usuarios.
Con el gran crecimiento experimentado por la red, con más de 955 millones de usuarios
en verano de 2012 se llega a la comprensión de que las complicaciones derivadas de tanta
gente compartiendo información, empiezan a aparecer complicaciones.
Gente que comparte información de terceros sin el consentimiento de estos, personas

que suben fotos inapropiadas, usuarios que quieren compartir información solo con unos
pocos.
Surgen además aplicaciones que permiten compartir información de manera automáti-

ca, así se da el caso de personas que han llegado a divorciarse por culpa de información
puesta por estas aplicaciones, como un marido que no va de viaje con su mujer por que
dice quedarse a trabajar y compra unos billetes a una línea aérea, que le da más puntos
si enlaza su cuenta de Facebook con la aplicación de la línea aérea y esta publica que su
vuelo ha sido puntual y placentero en su muro, cuando él afirmaba no estar viajando.
También se da el caso de fotos aparecidas en Facebook, en las que aparecían con “amigos”
o simplemente haciendo actividades cuando decían estar enfermos y por eso no iban a la
oficina, etc.
Por lo tanto, en un momento dado se ve la necesidad de regular el acceso que la red social
tiene a nuestra información y la información que nosotros mismos queremos compartir
con esta red social y con quiénes.
Con el crecimiento del número de usuarios, se llega al punto en que primero todo lo que
poníamos era visible por todo el mundo, poco a poco esto va evolucionando de tal forma
que nosotros podemos elegir si queremos que lo vea todo el mundo, nuestros amigos, o
los amigos de nuestros amigos. Así, poco a poco, continua la evolución, para que solo sea
visto por un conjunto de personas concretas, y no todos nuestros amigos (fotos de cosas
del trabajo que solo interesan a este grupo o la situación inversa, fotos que no queremos
que sean vistas en nuestro trabajo).
146
La llegada de los dispositivos móviles no facilitaba las cosas, al contrario, la facilidad para
generar contenidos, publicar mensajes o enviar fotos o videos hace que subamos cada vez
más información en un momento dado que posteriormente puede que nos arrepintamos
de haberlo hecho.
Facebook es uno de los entornos de Internet que tiene mayor propagación, como demues-
tra el gran número de usuarios activos que existen, como tal se ha visto envuelto en nu-
merosos problemas, que le han hecho ir evolucionando en cómo gestiona la privacidad
de los usuarios.
No es el único entorno de Internet donde nos podemos sentir amenazados, existen otros
muchos que pueden tener gran información de nosotros y hemos de saber gestionarlo.
En el caso de Facebook, si accedemos a nuestra cuenta, tendremos la opción de configurar

nuestra privacidad dentro de la propia página y definir qué y con quién queremos com-
partir la información, por defecto y luego podremos definir individualmente con quién
queremos compartir estos datos.
En Facebook, una de las herramientas que le da tanto valor a la red social es cuánto sabe
de nosotros y con quién comparte esa información, así Facebook es un gran gestor de
publicidad, los usuarios pasan muchas horas a la semana en su página gracias a la infor-
mación que voluntariamente o sin querer hemos ido añadiendo.
En la gestión de la privacidad y de las aplicaciones con las que compartimos información,

es importante conocer con quién y cuánta información compartimos, cada vez podemos
controlarlo mejor gracias a las presiones de los diferentes grupos de usuarios y gobiernos
para controlar ese tráfico de información.
Debemos, por lo tanto, tener conciencia de su existencia y de las posibilidades que ello
genera, los beneficios, pero también los inconvenientes, así muchas empresas nos piden
acceso a nuestra información de Facebook o a nuestro muro para publicitarse, pero tam-
bién para saber más de nosotros y ofrecernos aquellos productos que más nos pueden
interesar.
Una de las facetas más conflictivas de Facebook al principio era la política de baja de los
usuarios, porque en los contratos de entrada se firmaban (de forma digital) una serie de
cláusulas que le daban mucho poder a la empresa y le permitían controlar demasiado
todo lo que podíamos y no podíamos hacer, así como los derechos sobre las fotos y videos
que subíamos a la red social.
147
Esta política de propiedad llevaba a mucha gente a intentar darse de baja, pero, aunque la
persona quisiera cerrar su cuenta, los elementos vinculados seguían en la red.
Poco a poco, y tras quejas de usuarios y gobiernos, han ido modificando los procedimien-
tos y las cláusulas para permitir a los usuarios darse de baja de la red social.
De esta manera, ahora tendremos que rellenar un formulario en el que solicitaremos la

baja de nuestra cuenta de usuario, y la baja de nuestros datos, el procedimiento seguido
por parte de la compañía es que estos quedarán en cuarentena durante un periodo de
tiempo de dos semanas y si durante ese tiempo no volvemos a acceder por ningún medio
a nuestra cuenta, esta será dada de baja.
No todas las redes sociales funcionan igual, aunque sí de maneras bastante similares, así
por ejemplo en Twitter la baja se hace efectiva pasado un periodo de 30 días.
16.5. Privacidad en la empresa

Si bien generalmente cuando hablamos de la privacidad pensamos en nuestros datos per-
sonales, también debemos de tener en cuenta que también existe como concepto para las
empresas.
Por un lado, tendremos la obligación de cumplir con la legalidad vigente en materia de

protección de datos, cada país tiene una regulación diferente en cada caso que nos prote-
ge o nos regula a los consumidores y usuarios y obliga a las empresas. En el caso español,
la LOPD (Ley Orgánica de Protección de Datos) con la AEPD (Agencia Española de Pro-
tección de Datos) es su garante.
Como empresa tendremos una serie de datos personales que vamos a controlar y mante-
ner como pueden ser los datos de nuestros clientes, datos económicos y personales de los
empleados y en ocasiones, datos de futuros o potenciales clientes, para poder funcionar
con eficacia tendremos que proteger toda esta información.
En el mundo empresarial, podremos incluso asociar la responsabilidad social corporativa

con el hecho de controlar y cuidar la información que gestionamos y manejemos. De-
beríamos aprovechar las herramientas tecnológicas que nos facilitan proteger toda esta
información, tratarla, aprovecharnos de ella, pero siempre respetando que los datos co-
rresponden a personas y deberíamos cuidar manejarnos con las debidas garantías.
Una práctica corriente en las empresas es la obligatoriedad de firmar un contrato de con-

fidencialidad de los datos manejados, no solo por los propios datos empresariales sino
también de los de los empleados y clientes.
148
16.6. Privacidad y publicidad

Cada vez más en las empresas se utilizan campañas de publicidad para capturar datos de
los clientes, así sortean productos, viajes o simplemente un libro para conseguir informa-
ción de los usuarios, a cambio, estos han de rellenar un formulario, en que revelan una
serie de datos a la empresa.
Todo este tipo de formularios son una fuente de acceso a los datos para las empresas, aun-
que están obligadas a revelar qué es lo que van a hacer con ellos, incluso si los van a ceder
a otras empresas del grupo, y cómo vamos a poder acceder para que nos den de baja.
Para ayudar a proteger a los usuarios del posible abuso por parte de las empresas, existen
mecanismos de defensa para los consumidores como son las listas Robinson, donde nos
daremos de alta si no queremos que nuestros datos sean usados para publicidad (siempre
y cuando no seamos nosotros los que voluntariamente y posterior a la incorporación a la
lista Robinson hemos facilitado estos datos) es decir, entornos que ayudan a los usuarios
a protegerse frente al acoso de las empresas para venderles sus servicios.
16.7. Conclusiones
Una de las cosas que más enganchan y que más atraen de Internet es poder conocer cosas
del resto o como decía George Bernard Shaw: las cosas acerca de las cuales la mayoría de
la gente quiere saber son en general aquellas que no son de su incumbencia.
Eso nos lleva a compartir información, a cambio de información de otras personas. Una de
las cosas de las que tendremos que ser conscientes es de todos nuestros datos que están
libremente circulando por Internet, sin nuestro control y tratar de regular o controlar la
información que queramos que la red en general sepa de nosotros.

• Estamos constantemente sujetos a amenazas a nuestra privacidad y a nuestra se-

guridad cuando entramos en Internet, por ello deberemos implementar políticas
que nos protejan y nos ayuden a estar lo más seguros posibles.
• Las cookies son componentes que nos ayudan a la navegación, pero un peligro
para la publicidad, debemos conocerlas y para qué sirven.
149
17. Confianza y confidencialidad en

medios digitales
“El establecimiento de pasarelas seguras para la comunicación y

el funcionamiento con entornos es parte fundamental en el entorno
actual de las redes y para poder trabajar y operar de manera rápi-
da y eficiente.”
17.1. Comercio electrónico

El auge del comercio electrónico es un hecho a nivel mundial, ya que crece constante-
mente todos los años, entre otras cosas por la posibilidad de conseguir mejores ofertas se
encuentren estas donde se encuentren, gracias a que no necesitamos recorrer físicamente
todas las tiendas.
El inconveniente viene cuando queremos hacer la compra, la necesidad de conseguir un

método que satisfaga a ambas partes, por parte del usuario que acepte pagar a través de
ese método de pago, ya que la presencia física es evidentemente imposible o no sería una
compra a través de medios electrónicos, y por parte del comerciante que esté de acuerdo
en aceptar esa forma de pago para realizar la transacción.
La compra a través de Internet requiere confianza en el vendedor, ya que este nos tendrá
que enviar el producto adquirido (generalmente a través de mensajería) y que este se
ajustará a las condiciones establecidas en el contrato de compra.
Esta problemática hizo surgir empresas como PayPal orientadas al pago a través de Inter-
net, que permitían “bloquear” el pago de los bienes adquiridos hasta garantizar la llegada
de los mismos.
La aparición de este tipo de empresas, motivo por el que las herramientas tradicionales de
pago, como las tarjetas de crédito, comenzaron a desarrollar medios que permitieran los
pagos de forma segura a través de Internet.
Esto lleva a la aparición de pasarelas de pago, que mediante páginas seguras nos permi-
ten introducir los datos de nuestra tarjeta de crédito, incluidos los códigos de validación,
para garantizar que somos nosotros quienes realizamos los pagos.
150
En los últimos años hemos visto la aparición del medio de pago EMV, que nos obliga a
autentificar los pagos introduciendo un código de validación que autentifique que somos
nosotros quien estamos haciendo la compra. Esto es importante, ya que será el receptor
del pedido quien deba de estar seguro de que es el usuario quien hace el pedido.
Si nos encontramos en la tesitura de que un pedido llega a un proveedor y si posterior-

mente el titular de la tarjeta dice que ha sido efecto de un fraude y que él no ha realizado
esa compra, es obligación del vendedor certificar o garantizar de alguna manera que la
persona que ha realizado la compra es realmente el titular de la tarjeta.
La pérdida en la que se incurre es responsabilidad, no del comprador (usuario de la tarjeta

de crédito), ni siquiera de la propia empresa que haya dado la tarjeta de crédito (por ejem-
plo, VISA, MasterCard, American Express, Dinners Club, etc.), ni por el banco emisor de
la tarjeta o que haya puesto el terminal de pago, sino que será responsabilidad de la tienda
que acepta el pago.
Por ello se pide una firma que autentifique la compra, se nos pide un documento de iden-
tificación con foto o la introducción de un código de validación. Estas comprobaciones en
persona son más sencillas, pero en Internet se han de establecer métodos que nos permi-
tan garantizar esta autenticidad de las personas.
Las pasarelas de pago son, por lo tanto, un elemento importante para generar confianza
entre los usuarios y los vendedores y es uno de los entornos principales para las ventas a
través de Internet.
En el momento de crear la tienda electrónica deberíamos tener en cuenta no solo la fa-

cilidad de uso y la forma de distribuir las ventas que realicemos, sino también habrá que
considerar la forma en la que se implementará esta forma de vender.
Al igual que nos pasa en las tiendas cuando ponemos un TPV (Terminal Punto de Venta)
para facilitar el pago con medios de pago electrónico, estos vendrán ofrecidos por los
bancos o empresas de tarjetas de crédito, que a cambio de esta herramienta nos cobrarán
una comisión por las ventas, para poner una pasarela de pago en nuestra página de co-
mercio electrónico serán los bancos o proveedores de tarjetas (o el propio PayPal) quien
nos ofrezca esta pasarela a cambio de una comisión por las ventas realizadas.
Esta será una forma de introducir confianza en las transacciones comerciales, tanto desde
el punto de vista del vendedor como desde el del comprador.
151
17.2. Confidencialidad
Si la confianza es algo imprescindible para el desarrollo de Internet, la confidencialidad
de la información es también un componente que debemos de garantizar para que apa-
rezca y proliferen las operaciones.
Hoy en día, damos por seguro que los elementos van a funcionar y nos van a dar el resul-
tado que queramos, entre ellos la confidencialidad.
La confidencialidad es la propiedad que tiene la información por la que se garantiza que

solo las personas que lo necesiten tendrán acceso a la misma. Según la normativa inter-
nacional ISO 17799 garantizar que la información es accesible sólo para aquellos autori-
zados a tener acceso.
La forma normal de conseguir la confidencialidad hoy en día es mediante la encriptación.

La encriptación o uso de la criptografía es una técnica que aparición en la antigüedad por
la que intentamos ocultar un mensaje de tal forma que solo el receptor sea capaz de leerlo.
La palabra criptografía proviene del griego kryptos, que significa esconder y graphein,
escribir, es decir, escritura escondida y se divide en dos grandes ramas:
• La criptografía de clave privada o simétrica.
• La criptografía de clave pública o asimétrica.
La criptografía surge como una solución a los cuatro grandes problemas de la seguridad:
• Privacidad.
• Integridad.
• Autenticidad.
• No repudio.
17.2.1. Privacidad
La privacidad se refiere a que la información solo pueda ser leída por el destinatario. Si
mandamos una carta y, por alguna razón, alguien rompe el sobre para leer la carta, ha vio-
lado la privacidad. En Internet es muy difícil estar seguros que la comunicación es priva-
da, ya que no se tiene control de la línea de comunicación. Por lo tanto, al cifrar (esconder)
la información, cualquier intercepción no autorizada no podrá entender la información.
152
17.2.2. Integridad
La integridad se refiere a que la información no pueda ser alterada durante la comunica-
ción. Si pagamos una factura y la cantidad es incorrecta, menor, por ejemplo, tendremos
problemas. La integridad es muy importante en las transmisiones militares ya que un
cambio de información puede causar graves problemas.
En Internet las compras se hacen entre dos ubicaciones muy distantes, viajando por una
línea de comunicación de la cual no se tiene control. Si no existiera integridad, podrían
cambiarse por ejemplo el número de una tarjeta de crédito, los datos del pedido: informa-
ción que causaría problemas a cualquier comercio y cliente.
La integridad también se puede solucionar con técnicas criptográficas, particularmente

con procesos simétricos o asimétricos.
17.2.3. Autenticidad
La autenticidad se refiere a que se pueda confirmar que el mensaje recibido haya sido
mandado por quien dice que lo mandó o que el mensaje recibido es el que se esperaba.
Cuando se quiere cobrar un cheque a nombre de alguien, quien lo cobra debe de someter-
se a un proceso de verificación de identidad para comprobar que, en efecto, es la persona
quien dice ser. En general, se lleva a cabo mediante una identificación que certifica y
acredita la identidad de la persona que la porta.
La verificación se lleva a cabo comparando la persona con una foto o con la comparación
de una firma convencional.
Por Internet es muy fácil engañar a una persona con quien se tiene comunicación res-
pecto a la identidad mediante phising o cuentas en redes sociales que suplantan perso-
nalidad. Para poder verificar la autenticidad tanto de personas como de mensajes, usan
quizá la más conocida aplicación de la criptografía asimétrica que es la firma digital, que
podemos decir que remplaza a la firma autógrafa que se usa comúnmente.
17.2.4 No repudio
El no rechazo o no repudio se refiere a que no se puede negar la autoría de un mensaje
enviado. Por ejemplo, una carta o un correo electrónico que se envía con un remitente y
este niega haberlo enviado.
Existiendo múltiples formas de encriptar los mensajes utilizando la criptografía debere-

mos elegir aquella que nos permita aprovechar sus ventajas sin complicar demasiado el
uso normal de las comunicaciones y los sistemas.
153
17.3. Conclusiones
En los medios digitales, Internet está en constante evolución y el avance depende de
cómo los usuarios podemos tener garantía de que nuestros datos y nuestra información
se encuentran protegidos dentro de la misma, así irá evolucionando e iremos aceptando
todos los nuevos métodos y tecnologías que aparecen.
Continúan apareciendo elementos como métodos de pago nuevos que involucran compo-
nentes como los teléfonos móviles como es el caso de Square, una compañía que permite
utilizar el móvil como un terminal de pagos, con la simple descarga de una aplicación y
que si queremos nos puede servir para pasar tarjetas de crédito en la tienda.
Hace años la aparición de PayPal supuso una revolución en los métodos de pago online,
tanto que la plataforma de subastas eBay acabó comprando la empresa para garantizar
sus pagos y como herramienta de crecimiento.
Constantemente aparecen formas y métodos de aprovechar las nuevas tecnologías para

que en nuestro día a día podamos mejorar la forma en la que trabajamos y vivimos.
Está dentro de nosotros ser capaces de incorporar en nuestras empresas estas tecnolo-
gías de forma que podamos aprovecharnos de ellas, pero para que las nuevas tecnologías
terminen de calar en nosotros y se puedan desarrollar deben garantizar la utilización y la
observación de la confidencialidad de los datos y tendrán que generar confianza en los
usuarios.
Hay elementos como fue el ataque a Sony del que hablamos en una unidad didáctica
anterior que pueden hacer retroceder mucho a la empresa en estos factores y recuperar
la confianza de los usuarios no es tarea fácil ni barato, muchas veces deberíamos incen-
tivarlos a probar las mejoras que hemos introducido dentro de nuestros sistemas y como
estos garantizan su seguridad para que vuelvan.
El mundo de las redes sociales es un entorno que estamos constantemente observando

y analizando por la cantidad de información que se mueve y cómo nos pueden influir las
fugas de información y seguridad dentro de las mismas.
Caso aparte merece el caso de Google y la cantidad de información de los usuarios que
tiene hoy en día, que nos puede hacer temer sobre el uso que haga de toda esa informa-
ción, pero si no confiamos en estas empresas, difícilmente podremos avanzar, por eso
ponemos en sus manos grandes cantidades de información, a cambio de los servicios que
nos ofrecen. Este intercambio lo aceptamos por la confianza que nos merecen, pero no
siempre está justificada.
154
Los grandes motores de la información son empresas que manejan ingentes cantidades
de datos de los usuarios y por ello de forma repetida los podemos ver en los periódicos
porque o bien asociaciones de usuarios o bien gobiernos han interpuesto demandas con-
tra ellas, pero que sin esas empresas la vida e Internet no sería como hoy la conocemos.
En los años venideros deberíamos estar preparados para grandes cambios y como las em-
presas nos pedirán que confiemos en ellas a cambio de servicios y mejoras para nuestra
vida, que claramente ha ido cambiando sin nosotros notarlo.
A cambio de esa confianza y esa información que nosotros les daremos, nosotros les pe-
diremos que traten esa información de manera confidencial y que nos permitan acceder a
toda la información que almacenan de nosotros.

Factores en los que importa la confianza como en el establecimiento del comercio electró-
nico y la importancia de mantener la fiabilidad y confiabilidad de los datos.
Dato importante
El uso de las tecnologías de la información nos permite cada vez más facilidades y
el uso de las mismas para entornos como pagos bancarios, presentar documentos
en la administración pública o realizar una compra a través de la red. Para que esto
se pueda realizar, hemos de ser capaces de garantizar el correcto funcionamiento
de las transacciones, y establecer entornos seguros en los que se pueda confiar; que
podamos creer en ellos.
155
18. Seguridad en la nube

“Las herramientas de los entornos Cloud proveen de conexiones a
través de protocolo seguro, que nos garantice que la información
no solo llega a su destino, podremos establecer una comunicación
directa y establecer protocolos de paso de información utilizando
certificados seguros en la misma.”
18.1. Antecedentes
A finales de febrero de 2010 un día se vivió el caos: el caos de confiar demasiado en los
servicios de otros. El correo electrónico de Google, Gmail, estaba caído. Con él se hundían
los mails de presentaciones aburridas en cadena, los mensajes personales o los números
de reserva del avión que el usuario X tenía que coger al día siguiente. Y con él se hundían
también todos aquellos usuarios corporativos que usan las herramientas de Google para
gestionar su correo electrónico empresarial.
Las primeras hipótesis apuntaban a un ataque exterior, pero finalmente Google confesó
que la culpa no era más que suya. “En el día de ayer se produjo un inesperado efecto
secundario provocado por un nuevo código que trata de mantener los datos geográfica-
mente próximos a los titulares de las cuentas”, aseguraban entonces. Los clientes corpo-
rativos se pusieron en pie de guerra y los costes de la caída (de un día) se estimaron en
miles de millones de dólares.
Pero lo peor fue el impacto que la caída tuvo en la imagen del Cloud Computing. El correo
en la nube de Google fue el primer servicio Cloud que presentó un fallo importante.
En el entorno actual de los sistemas de información, tenemos cada vez más datos dis-
tribuidos y comenzamos a tener practicas que nos pueden llevar a utilizar sistemas de
computación en la nube.
El 7 de agosto de 2011 un rayo cae en una subestación eléctrica de Dublín, lo que podría
ser un hecho natural sin más, lleva como consecuencias un incendio que causó un apagón.
Este apagón se llevo por delante el CPD de Amazon en Dublín, desde donde daba servicio
tanto a sus sistemas web como al mundo Cloud con su oferta de internet EC2 (Elastic
Cloud Computing) el modelo más alto de la gama en la que se garantiza un rendimiento
de los sistemas del 99.95% de disponibilidad (Un tiempo de caída a lo largo de todo el año
de 260 minutos aproximadamente) y la garantía de que todos los datos almacenados en él
se quedarán disponibles en la zona (Por temas legales de cumplimiento de LOPD y otras
regulaciones muchos clientes demandan este tipo de servicios).
156
La caída del CPD de Amazon, si bien fue una consecuencia en cadena de varios factores,
desencadenados por el rayo, provocó la caída durante varios días de miles de sistemas en
toda Europa, servicios como PayPal, Filmin o Menéame se vieron afectados y no pudieron
operar con normalidad hasta pasada una semana
Nos planteamos como el hecho de sacar nuestros sistemas de computación fuera a entor-
nos orientados y diseñados para ello puede ayudarnos a tener una plataforma controlada
y vigilada, que nos permita garantizar acceso desde cualquier punto y que nos ayude a
liberarnos de las cargas fiscales derivadas de la instalación o diseño de la infraestructura
en nuestros sistemas.
En los Data Center en la nube, los servidores normalmente son virtualizados y comparti-
dos por múltiples departamentos o clientes, y no son más dedicados a líneas o negocios
específicos. Esto generó nuevas preocupaciones con la seguridad.
La diferencia en la seguridad es comparable a vivir en la propia casa o en un apartamen-

to alquilado. Cuando se es dueño de la propia casa, hay un significativo control sobre la
protección y la seguridad podemos poner candados y muros, hasta sistemas de alarma o
cualquier otro entorno. Esto se compara a la actual seguridad de las TI de las empresas.
Sin embargo, cuando se vive en un apartamento alquilado, es como estar en un ambiente
con múltiples inquilinos, donde las diversas personas comparten las mismas áreas, gene-
rando preocupaciones con la seguridad. Que alguien entre al apartamento por las escale-
ras de incendio o quizás que el propietario entre cuando un inquilino no esté aumentan
las preocupaciones con la seguridad. Dicha situación es similar a tener menos control en
su ambiente de computación en la nube.
En un reciente estudio global con profesionales de TI sobre la seguridad en la nube, y rea-

lizado por Intel, 61% de los profesionales de TI expresaron preocupaciones con la falta de
control y las capacidades de estos recursos compartidos en los Data Center virtualizados.
Los profesionales de TI también expresaron preocupaciones por no tener las herramien-
tas adecuadas para la protección contra los ataques virtuales, y 57% no hospedarán datos
sensibles que deben cumplir requisitos específicos de compatibilidad en los Data Center
en la nube.
La realidad por lo tanto es que la nube es un nuevo entorno, que difiere de lo que está-
bamos habituados a manejar hasta el momento y como tal tendremos que plantearnos
nuevas políticas de seguridad y nuevas formas de actuación.
Como nueva tecnología, trae muchas ventajas y grandes beneficios, pero no se deben de
descuidar los riesgos novedosos que deberemos medir y controlar
157
18.2. Politicas imprescindibles

Como cualquier solicitud de servicios, es necesario y obligatorio tener un acuerdo respec-
to al nivel de servicios que se está solicitando, como tal deberemos medir que los niveles
de servicio prometidos se están cumpliendo.
En todo momento debemos tener en cuenta que si nos ponemos en situación de lo peor
podremos protegernos por si algo sucede, ya que lo habremos previsto.
Una de las características del mundo Cloud es tener servicios elásticos, lo que nos permite
pagar tan solo por lo que usamos y no por diseños maximizados para futuros crecimien-
tos. El tener el entorno diseñado para crecer y solo pagar por lo que gastamos si nos refe-
rimos al mundo SaaS nos permite decir que pagamos por usuarios que estén trabajando.
Si estamos en un entorno de SaaS, nuestros datos se pueden encontrar por lo tanto al-
macenados dentro de los servidores del proveedor. Deberemos de establecer estrategias
de Backup de forma equivalente a si nos encontramos en un entorno que se encuentre
alojado en nuestras propias infraestructuras.
Realizar Copias de Seguridad de los datos podremos hacerlo a entornos locales o aprove-
char también herramientas de seguridad que podemos encontrar en la nube.
Normalmente los proveedores de servicios en Cloud están sensibilizados frente a estas

incidencias y por eso establecen estrategias para poder hacerlo.
En el momento de seleccionar nuestro entorno online por lo tanto tendremos que selec-
cionar que nos permita y cómo nos permite hacer este tipo de copias de respaldo.
Si hablamos de un entorno de IaaS o Infraestructura como Servicios, el tipo de Backup es

diferente, ya que no consiste únicamente en realizar la copia de seguridad de los datos,
con las api o aplicaciones que nos ofrezcan, también es importante tener copia de todo lo
que hayamos ido incorporando dentro de su entorno, tanto aplicaciones como configura-
ciones y por supuesto los datos.
La creación o la utilización de una infraestructura como servicio nos proveerá de una

infraestructura, esa infraestructura se encuentra por lo tanto en sus dependencias y ellos
se han de encargar de la seguridad física, elementos tales como la refrigeración, el acceso
físico a los sistemas, control del fuego en caso de poder haberlo, corriente eléctrica, etc.
Sin embargo, la seguridad lógica de una Infraestructura como Servicio quedará a cargo
de los usuarios. Por ello deberemos asegurarnos de estar realizando conexiones seguras
en todo momento.
158
Las herramientas de los entornos Cloud proveen de conexiones a través de protocolo

seguro, que nos garantice que la información no solo llega a su destino, podremos estable-
cer una comunicación directa y establecer protocolos de paso de información utilizando
certificados seguros en la misma.
Podemos en el caso de subir información y que nos interese, encriptar esta información
antes de proceder a su envío y desencriptarla luego en el destino para conseguir que todo
el tiempo la información permanezca codificada, para ello podremos usar mecanismos de
encriptación de nuestra elección.
Si estamos hablando de la infraestructura como servicio también podemos plantearnos

la utilización de sistemas de antivirus, para evitar que cualquier dato que pueda llegar a
nuestros sistemas, bien desde nuestro entorno bien desde los usuarios no pueda atacar el
resto de sistemas involucrados.
Utilizar sistemas que nos permitan garantizar la prevención de ataques, generalmente

los entornos de Cloud están concienciados con nuestra seguridad (Su negocio depende
de ello y no quieren ni pueden permitirse brechas en la misma) así que en ocasiones nos
podrán proveer de mecanismos de respuesta.
Hay distintos niveles de acceso, deberemos de tener cuidado con la gestión de contrase-
ñas que hagamos en nuestro entorno y cambiarlas y sustituirlas con la frecuencia necesa-
ria para que el entorno se mantenga seguro y protegido.
Hemos de tener en cuenta que si bien los sistemas distribuidos en internet (Cloud) nos
proveen de entornos con una cierta seguridad las aplicaciones y sistemas que pongamos
dentro, bien desarrollados por nosotros, bien por terceros, deben de ser tratados de la mis-
ma manera que cualquier otro entorno, si es una programación nuestra, debe de ser de tal
manera que nos garantice la seguridad, código bien estructurado y sistemas siguiendo las
distintas políticas y estructuras de sistemas.
Si estamos utilizando sistemas de terceros establecidos por nosotros, deberemos asegu-

rarnos de cumplir con las mismas políticas de actualizaciones y revisiones que en otros
entornos.
En una infraestructura SaaS, contamos con la ventaja de que nosotros no nos encargare-
mos de estas actualizaciones (nos ceñiremos a las infraestructuras que nos ofrezca nues-
tro proveedor) lo cual nos facilita más el funcionamiento, pero sí debemos comprobar que
se siguen en caso de ser necesario.
159
Una de las ventajas a nivel de seguridad de los entornos de Cloud Computing en modelo
SaaS es que el software suele ser entorno propietario, que cada empresa de desarrollo ha
realizado a su medida, para aprovecharse de las ventajas que esto conlleva. Como usua-
rios a nivel de seguridad eso nos beneficiará, ya que indica que los posibles hackers que
quieran atacar el entorno carecerán de información de los sistemas (existe mucha menos
documentación publica de estos entornos privados) y por lo tanto les será más complica-
do encontrar huecos en su seguridad.
Nuevamente como en el caso de los entornos IaaS hemos de comprobar y garantizar que
las comunicaciones se hacen a través de entornos seguros, incluso si cabe la posibilidad
de que sea una comunicación privada con nuestra empresa (Cuando la conexión se rea-
lice desde nuestras oficinas) para así proteger el envío y recepción de información entre
nuestros sistemas y el Cloud Computing.
18.3. Estrategia de salida

En cualquier infraestructura o entorno hacia el cual traslademos los sistemas de nuestra
empresa, tanto si es una actualización de sistemas por un nuevo software, si es un entorno
de hosting donde alojaremos nuestras maquinas o si nos estamos trasladando al mundo
Cloud, deberemos tener establecidas unas estrategias que nos permitan una vuelta atrás.
En los entornos de Cloud Computing esto muchas veces se nos complica un poco, ya que
todas las empresas se encargan de desarrollar estrategias que nos faciliten el paso a sus
infraestructuras, pero las herramientas y elementos que nos faciliten la vuelta atrás están
generalmente menos evolucionados.
Si estamos moviéndonos hacía un entorno IaaS, básicamente lo que haremos será aprove-
char su infraestructura, con lo que el paso hacia atrás puede ser razonablemente sencillo,
tan solo necesitamos una infraestructura donde montar los sistemas que ya teníamos.
Al tratarse mayoritariamente de entornos virtualizados nos ofrecen herramientas que

permiten la virtualización de nuestros sistemas, el paso contrario muchas veces no es in-
teresante, lo interesante sería traer nuevamente la maquina virtual con nosotros y montar
nuestra infraestructura nueva de virtualización.
Si lo que nos planteamos es una plataforma como servicio PaaS como puedan ser Azzure
de Microsoft, Force.com de SalesForce o Google App, lo que haremos será desarrollar
e integrar nuestras aplicaciones dentro de su estructura, en ese caso, lo que nos va a
interesar sería realizar un desarrollo paralelo que pueda funcionar en infraestructuras y
plataformas tradicionales que pudiéramos tener nosotros en local, o desarrollar en más
de una plataforma.
160
Cuando estamos haciendo estos desarrollos, el inconveniente es el habitual, según se

acerca la fecha de entrega o finalización de los proyectos, centraremos nuestros esfuerzos
en la plataforma operativa, quedando nuestra vía de salida comprometida. Debemos pro-
curar que esto no suceda.
En los entornos de SaaS, nos puede suceder cosas similares, pero estos entornos al permi-
tirnos en muchas ocasiones estar haciendo copias de seguridad de nuestros datos y que
podamos mantener nosotros la información, como pudiera ser en el caso de Microsoft
Dinamycs o de SalesForce, o las herramientas de Google App, que permiten operar de ma-
nera offline y por lo tanto ya tendríamos la información en nuestro poder, la salvaguarda
de los datos queda casi expresada de manera automática.
18.4. Conclusiones
La creación de una estrategia de seguridad en entornos Cloud no difiere de las estrategias
que deberemos de plantearnos para los entornos offline, deberemos de considerar los
activos que tenemos, los riesgos a los que nos enfrentamos y de acuerdo a ello plantear
nuestra estrategia de seguridad.
Diferirá, eso sí, en que las plataformas físicas tienen menos importancia ya que todo lo
haremos online, pero deberemos encargarnos de la protección de los datos en el medio
online y proponer la estrategia adecuada.

En esta unidad didáctica hemos podido ver:
• El Cloud es una herramienta útil y práctica para la empresa actual, pero como
todas las herramientas tecnológicas conlleva sus riesgos, hay que saberlos, prepa-
rase y actuar en consecuencia.
Dato importante
Si bien los sistemas distribuidos en internet (Cloud) nos proveen de entornos con
una cierta seguridad las aplicaciones y sistemas que pongamos dentro, bien desa-
rrollados por nosotros, bien por terceros, deben de ser tratados de la misma manera
que cualquier otro entorno, si es una programación nuestra, debe de ser de tal ma-
nera que nos garantice la seguridad, código bien estructurado y sistemas siguiendo
las distintas políticas y estructuras de sistemas.
161
19. Seguridad en tecnologías móviles
“Los dispositivos móviles son potentes herramientas para las em-

presas y gracias a su disponibilidad (teléfonos móviles y tabletas) y
movilidad pueden ser más agiles y dinámicas. Muchos de los siste-
mas de software ya incluyen en sus desarrollos plataformas de ac-
ceso a través de los dispositivos móviles, lo que nos puede facilitar,
si uno es vendedor, meter datos de forma remota y rápidamente.”
19.1. Amenazas móviles
19.1.1. Malware
La ausencia de seguridad y la gran adopción de dispositivos móviles han hecho proliferar
el malware destinado a ellos. Así, según un estudio de la firma de seguridad y redes Juni-
per Networks afirmó que entre los años 2009 y 2010 se incrementaron las amenazas en un
250%. Prácticamente todas las plataformas de entornos móviles se volvieron potenciales
objetivos.
Incluso los entornos a través de SMS que incluían troyanos dentro del mensaje, aplicacio-
nes que hacían llamadas de larga distancia que incrementan las facturas, aplicaciones de
detección de pulsaciones que detectan las contraseñas, aplicaciones que se auto propa-
gan y se renvían a todos los contactos de la agenda.
Cada vez surgen amenazas más y más sofisticadas, que incluso hacen que el malware
cambie durante su propagación para evitar su detección y limpieza.
Las aplicaciones de spyware también han sufrido un gran crecimiento, aplicaciones que
monitorizan todas las actividades y en ocasiones permiten tomar el control de manera
remota a los dispositivos controlados por los cibercriminales.
Existen incluso aplicaciones comerciales que permiten ocultar su presencia dentro del
dispositivo. Para poder detectar este tipo de malware es necesario potentes aplicaciones
diseñados al efecto.
162
Las aplicaciones de spyware pueden permitir al atacante leer los SMS (mensajes cortos
de texto entre móviles), los MMS (mensajes multimedia que pueden incluir fotos, video o
mayores cantidades de texto), correos electrónicos y todo el tráfico de entrada y salida que
se produzca dentro del móvil, así como localizaciones o llamadas. Estos tipos de aplicacio-
nes pueden incluso permitir al atacante escuchar de manera remota las conversaciones
que tengan lugar en el teléfono móvil.
Visto las enormes capacidades de este tipo de software, si tenemos en cuenta la posible
utilización para temas de negocio de los teléfonos móviles, estaremos poniendo en peli-
gro nuestra empresa, la confidencialidad, integridad y disponibilidad de los datos de la
compañía.
El software de spyware no es algo nuevo en los entornos de seguridad, ni siquiera en los

sistemas móviles, pero la rápida proliferación de los dispositivos móviles inteligentes,
unido a la facilidad para conseguir este tipo de software y distribuirlo a través de las tien-
das de aplicaciones elevan el riesgo de la amenaza.
Combinada esta amenaza con las tendencias de BYOD hace que el entorno empresarial
deba protegerse frente a este tipo de ataques, personalizados o no, contra los datos y la
integridad de nuestra compañía.
19.1.2. Pérdida o robo

Otro de los grandes problemas que nos encontramos en los entornos móviles es la posi-
ble pérdida de los dispositivos, o el robo de los mismos.
La facilidad de movimiento y la movilidad que nos otorgan, nos facilita enormemente

el reaprovechamiento del tiempo ya que nos permite estar desplazándonos y continuar
conectados a la oficina o a las personas.
Cada vez más podemos hacer operaciones a través de los dispositivos como transferen-
cias bancarias, solicitudes de pedido, compras y numerosas aplicaciones profesionales
que crecen para entrar en nuestros dispositivos móviles y facilitarnos el acceso a las mis-
mas.
Una costumbre cada vez más frecuente es tener almacenadas las claves de acceso a nume-
rosos sistemas dentro de las propias aplicaciones, para no tener que recordarlas todas y
para no tener que estar introduciéndolas cada vez que entremos en el entorno.
163
La facilidad de recordarla, cuando hablamos de este tipo de entornos menos seguros, me-
nos protegidos, que fácilmente se pueden perder, olvidar o nos los pueden robar, hace que
sea una gran brecha para la seguridad, de las personas y de las aplicaciones y los sistemas
empresariales.
Una aplicación empresarial, a la que nos conectamos mediante el uso de una clave por un
servidor seguro y comunicación protegida, deja de ser un entorno seguro si le damos a
alguien un dispositivo de acceso con las claves.
Se calcula que al año se pierden más de 30 millones de dispositivos móviles en el mundo,

eso es mucha información y muchos sistemas que pueden ser vulnerados si hemos segui-
do alguna de estas prácticas en nuestros dispositivos.
19.1.3. Herramientas de pago electrónico

En los entornos de las tecnologías móviles uno de los avances que va llegando con más
fuerza es poder utilizar el teléfono como medio de pago, facilitándonos la vida, al permi-
tirnos simplificar nuestras carteras, eliminando la necesidad de tener tarjetas de crédito
encima constantemente.
Ya tenemos en algunos dispositivos elementos como el RFID (Radio Frequency Identifi-

cation) que es la tecnología en la que se basa en NFC (Near Field Communication) una
tecnología que permitirá el pago simplemente aproximando el teléfono móvil al disposi-
tivo de cobro y posteriormente introduciendo la clave de nuestro servicio.
El problema que nos encontramos en esto, es que esta comunicación se hace a través de
un entorno de radio que proviene de una etiqueta que tiene los datos almacenados, o que
genera nuestro teléfono móvil identificando el dispositivo.
Este sistema de RFID es el mismo que se utiliza en etiquetas para la distribución, o para
entornos de oficina, para abrir puertas y detectar personas.
Mientras la tecnología RFID está ampliamente extendida, a la hora de implantar un entor-

no seguro que nos permita hacer los pagos y garantice la seguridad, complica las transac-
ciones, la tecnología RFID es ampliamente conocida, si a eso le sumamos que en alguna
ocasión (a modo experimental con grandes sistemas dedicados a ello) se ha conseguido
saltar los protocolos de seguridad de las empresas que como VISA o Google trabajan en
el desarrollo de la tecnología, esta ofrece comodidades, pero también hay que tener cui-
dado y establecer mayores controles derivados de su uso.
164
19.2. ¿Qué podemos hacer?

Dada la naturaleza de las amenazas antes expuestas (habrá más, pero es por indicar y
presentar algunos de los riesgos existentes en la tecnología) deberíamos de tratar de im-
plementar políticas contra estos riesgos dentro de los sistemas.
Tendremos que conseguir y establecer una política de protección contra el malware, del
mismo modo que hacemos con los ordenadores y los servidores de la empresa, debe-
ríamos establecer una política con sistemas antivirus que permitan la detección de los
malware antes de su llegada y el escaneo de los sistemas.
Es necesario disponer de un software que nos permita detectar no solo listas de malware
conocidos, sino también heurísticas y nos advierta si llega algún mensaje o programa
sospechoso a nuestros dispositivos, para que podamos protegerlo, no solo ese dispositivo,
sino el resto de los que se encuentran en la red.
Protección contra robo y pérdidas: para mitigar los riesgos de un robo o una pérdida del
dispositivo, se tendrán que establecer herramientas que permitan la gestión remota de
dispositivos, que pueden incluir elementos como activar el GPS (Sistema de Posiciona-
miento Global) que nos puede servir para identificar la situación exacta del dispositivo.
Son también interesantes herramientas que permitan garantizar un backup de los datos
de los móviles, de tal forma que estos puedan ser remplazados rápidamente si el disposi-
tivo se vuelve inaccesible o se pierde.
En entornos empresariales también puede ser interesante el uso de herramientas que

permitan a los administradores de manera remota lanzar el backup del dispositivo, blo-
quearlo o eliminar cualquier información sensible dentro del mismo.
Otro de los riesgos existentes en el mundo de las comunicaciones móviles sería la inter-
ceptación de los datos en la comunicación, por ello si usamos el dispositivo para conec-
tarnos con nuestra empresa, sería interesante plantearnos el poder establecer una comu-
nicación mediante una VPN (Red Privada Virtual) que realice la comunicación de forma
encriptada y así poder garantizar las propias comunicaciones.
165
19.3. BYOD
Si establecemos en nuestra compañía tecnologías derivadas del uso de los propios dis-
positivos de los empleados, deberíamos empezar a facilitarles las conexiones y la forma
de trabajar.
Existen diferentes políticas que podemos tomar desde las empresas para permitir este
tipo de funcionamientos, pero también deberíamos dar facilidades para que esto sea ope-
rativo, ya que si solo imponemos complicaciones el entorno puede ser poco práctico.
Crear una red wifi a la que los dispositivos móviles se puedan conectar, que permita que
tengan acceso a Internet y si así lo queremos acceso restringido a nuestra red, estable-
ciendo las políticas de seguridad para dicha red y mejorando así la seguridad de nuestra
infraestructura.
Podemos crear herramientas que permitan el acceso desde estos dispositivos a perfiles
especiales, aprovechando las tecnologías de la virtualización, de tal forma que los dispo-
sitivos nos puedan servir de plataforma de acceso a un entorno virtual que sería el que se
encontraría protegido, si además protegemos el acceso, con comunicaciones encriptadas
y contraseñas de acceso, podremos mejorar la seguridad de nuestro entorno.
Establecer un mínimo soporte para las aplicaciones corporativas. Si bien el hecho de crear
una política de BYOD puede parecer una gran carga de trabajo extra para los sistemas
empresariales a nivel de soporte, la realidad es que este normalmente se debe de ver
reducido, el departamento de soporte de la empresa se dedicará a dar soporte a las aplica-
ciones y no al hardware de los usuarios, ya que este ha sido libremente elegido por estos.
Permitir políticas de BYOD puede redundar en la posibilidad de generar un mejor am-

biente de trabajo, permite que los usuarios se encuentren cómodos con sus dispositivos y
nos permite crecer y desarrollar nuevas estrategias de movilidad.
Si bien la creación de una red wifi dentro de nuestra empresa nos puede facilitar que estos
dispositivos se conecten, con permisos especiales y que necesiten de una nueva conexión
a los entornos empresariales a través de aplicaciones especiales o perfiles virtuales que
pueden ser ejecutados cuando queramos acceso a los sistemas, el problema viene cuando
aprovechándonos de la movilidad queremos acceder desde fuera.
Para poder acceder de manera remota a nuestros sistemas una posibilidad es la creación
de un entorno de VPN que permita las mismas ventajas que trabajar desde la red interna
de la compañía y nos dé al mismo tiempo la posibilidad de movernos y poder acceder a
los sistemas de manera segura y remota.
166
Si establecemos estas políticas de BYOD, damos acceso a la red de la empresa mediante

WIFI o VPN y facilitamos el uso de estos dispositivos, otra política necesaria dentro de
la empresa será establecer accesos diferentes dependiendo de los factores que nosotros
designemos, bien por punto de acceso por el que se trabaje (VPN o WIFI), dependiendo
del dispositivo, de contraseñas concretas de los usuarios o mediante cualquier otra va-
riable que se nos ocurra, que permita garantizar una granularidad de la información y
segmentarla.
Evidentemente, si establecemos este tipo de políticas, se deben incrementar el número de

veces que solicitamos validación a los usuarios, lo cual puede repercutir en un mínimo
inconveniente a cambio de las ventajas de poder disfrutar de los dispositivos.
Deberíamos, asimismo, establecer políticas que obliguen a instalar herramientas antivi-

rus (podemos incluso seleccionar una si así lo vemos conveniente especifica y compro-
bada por nosotros) que se actualice de forma periódica para evitar la proliferación del
malware, asimismo, podemos recomendar la idoneidad de hacer copias de respaldo de la
información, agenda, y archivos importantes que podamos tener en el teléfono.
Recomendar el uso de herramientas de rastreo del teléfono, con el fin de poder localizar-
lo en caso de pérdida y solicitar la implementación de las medidas de seguridad de los
teléfonos móviles, contraseñas de bloqueo de pantalla y de bloqueo de tarjeta, para que
cualquier persona que acceda a ellos no pueda entrar dentro de nuestros sistemas.
19.4. Conclusiones
La llegada de los dispositivos móviles a las empresas abre un abanico de oportunidades
que nos permite aprovechar mejor nuestro tiempo y disfrutar de más elementos y acceso
a los sistemas, pero en multitud de ocasiones (Internet está lleno de ejemplos en forma de
videos) los padres dejan a sus hijos los móviles o las tabletas para que estos jueguen con
ellos y se diviertan.
En ocasiones, se ve más sueltos a los hijos que a los padres con los dispositivos, esto hace,
que ellos puedan entrar en tiendas de aplicaciones de los distintos teléfonos y descargar-
se cosas como juegos o herramientas de acceso a redes sociales, algunas de las cuales
pueden incluir en su interior herramientas de malware para controlar los sistemas.
Es por tanto una fuente de beneficios a nivel individual y empresarial, el uso de los dispo-
sitivos móviles, pero también es una fuente nueva de riesgos de seguridad para las per-
sonas y las empresas y por ello, deberíamos tratarlo como nuevos elementos en nuestro
parque tecnológico que vamos a vigilar, proteger y controlar.
167
No es algo sencillo ir en contra del uso de los aparatos (máxime cuando en ocasiones se
solicita por imagen desde la dirección de la compañía el poder usar la última versión de
un teléfono o una tableta) por lo que es mejor prepararnos para su utilización e imple-
mentación dentro de la compañía, mostrando al departamento de sistemas y al entorno
de seguridad como una fuente de soluciones y no como un muro que detiene el desarrollo
de la empresa.

Amenazas para dentro del mundo móvil:
• Malware.
• Spyware.
• Pérdida o robo.
• Herramientas de pago.
Herramientas de protección frente a las amenazas:
• Software anti-malware.
• Endurecimiento de políticas de acceso.
• Establecimiento de políticas BYOD seguras.
Dato importante
Permitir políticas de BYOD puede redundar en la posibilidad de generar un mejor

ambiente de trabajo, permite que los usuarios se encuentren cómodos con sus dispo-
sitivos y nos permite crecer y desarrollar nuevas estrategias de movilidad.
168
20. Cómo elaborar un plan de

seguridad
“En muchos entornos no existe la seguridad absoluta y eso cuando
hablamos de los sistemas informáticos se aplica completamente.
Por lo que lo que debería de preocuparnos sería más bien cuáles de
nuestros sistemas están expuestos, qué programas son accesibles y
qué fácil es acceder a ellos y con todo esto preparar una respuesta.”
20.1. Antecedentes
En Estados Unidos se descubrió que un empleado de una agencia estatal se llevó a casa
algunos datos en un disco duro portátil para poder seguir trabajando allí, mientras tenía
los datos en casa, entraron y robaron en su vivienda, con la consiguiente pérdida de los
datos que implicaban datos de millones de beneficiarios de los servicios de la agencia.
La posterior investigación llevada a cabo reveló que:
• No había ninguna política clara e identificable en la que se prohibiese que emplea-

dos o subcontratados se llevaran trabajo a casa o lo sacasen de la agencia.
• No había ninguna política clara e identificable que indicase que los empleados o
los subcontratados debían conseguir una autorización para poder sacar los datos
de la empresa.
• No había ninguna política clara e identificable que prohibiese el uso de maquinas

de fuera de la agencia para el tratamiento de la información.
• No había ninguna política clara e identificable que obligara a proteger la informa-

ción con contraseña o con cualquier otro método de cifrado cuando la información
se guardaba en algún sistema o disco duro que no fuera de la agencia.
Si la agencia en cuestión hubiera tenido una política respecto al tratamiento de la infor-

mación sería menos probable que dicha pérdida de información se hubiera producido.
La creación de este plan, como hemos comentado en otras ocasiones, requiere de técnicos
capaces de establecerlo y de implementarlo, pero sin el liderazgo por parte de la direc-
ción, la creación del plan será una tarea inútil, ya que su implementación difícilmente
llegará a buen puerto.
169
Para definir este plan podremos seguir ocho pasos que nos llevarán a buen puerto para
conocer qué puntos debemos tratar y cómo deberemos de trabajar en ellos.
20.2. Identificar los activos

De la misma manera que las empresas no contratan guardias jurados encargados de la
seguridad que vayan armados para evitar que se hagan fotocopias, ni se guarda el dinero
de la compañía en un cajón sin vigilancia, las mismas ideas han de aplicarse a la hora de
establecer cuáles son los activos digitales de la compañía.
Una vez tenemos los activos de la compañía, deberemos determinar el riesgo relativo a
cada uno de ellos, ya que de esa forma se podrá determinar el grado de protección que
cada activo merece.
En un banco, por ejemplo, se podría asignar mayor cantidad de protección a la base de da-
tos que almacenan los datos financieros de los clientes y en una empresa farmacéutica a
lo mejor la mayor inversión se haría para los servidores de investigación donde se almace-
nan los datos sobre compuestos prometedores. Sin embargo, los servidores web internos,
que contienen información de carácter general o avisos, requerirán menos protección.
Una vez definidos los activos digitales, pasaremos a evaluar al personal, los procesos y
tecnologías que sirven de apoyo a los activos, para de esta manera tener una idea de
cuáles son los activos, cuánta protección merecen y quien deberá ser el responsable de
proporcionar esa protección.
20.3. Recursos de IT
Todas las empresas deben tener una política que explique la adecuada utilización de los
distintos recursos. Por ejemplo, un empleado debe saber lo que puede o no puede cargar
a la cuenta de gastos, pero en el caso de los recursos tecnológicos, la utilización de los
mismos suele estar menos clara.
Es necesario tener claras ciertas cuestiones como: ¿Quién debe tener acceso remoto a la
red de la empresa? ¿Qué protecciones son necesarias antes de que alguien pueda conec-
tarse de manera remota a los sistemas de la empresa?
Estas cuestiones no son elementos técnicos, sino que se trata de cuestiones de personal
y operativas y como tal corresponde a la dirección tomar las decisiones que ayudaran a
identificar los comportamientos de determinados puestos o trabajos, así como las tareas
que se deben y no deben hacer con los sistemas de cada empleado (como compartir con-
traseñas).
170
Como hasta la mejor de las políticas de seguridad es ineficaz si los usuarios y los socios
no la conocen y no la cumplen, es importante que las empresas expliquen los motivos de
las limitaciones establecidas para el uso de los sistemas de la compañía.
20.4. Controlar el acceso a los sistemas

No permitimos que la primera persona que pase por la calle entre en nuestras oficinas y
utilice la fotocopiadora o la máquina de fax, o intervenga en una reunión con un cliente.
De la misma forma, deberemos tener un control de quién puede y no puede acceder a
nuestro sistema.
Hacen falta herramientas y sistemas que nos permitan saber quién tiene acceso a infor-
mación concreta. Además, habrá que garantizar que las comunicaciones importantes son
protegidas y tratadas de acuerdo a estas especificaciones.
Hay ciertas tecnologías como los cortafuegos o firewalls, sistemas de autenticación y au-
torización, sistemas criptográficos, etc., que se pueden utilizar para satisfacer estas nece-
sidades, pero que solo son válidos en la medida en que lo sea la información introducida
en ellos.
Deben estar configurados para que reflejen las decisiones adoptadas a la hora de determi-
nar cuáles son los activos importantes y quién ha de tener acceso a ellos.
Por supuesto, los directivos no técnicos no serán quien se encarguen de configurar las
herramientas, pero sí que deben conocer las implicaciones y ser quien decida cómo van a
funcionar y quién tendrá acceso y quién no.
De la misma forma que se controlan los distintos elementos como suministros o estado
de los aparatos mediante auditorías programadas y controles aleatorios, también se ha de
comprobar el correcto funcionamiento de los sistemas informáticos de la empresa.
Los sistemas de supervisión y detección de intrusos suelen guardar normalmente toda la

actividad realizada en las redes y a través de ella detectar las actividades sospechosas, si
se han realizado cambios o pautas de funcionamiento.
Algunas empresas desconectan estas funciones de análisis porque dicen que ralentizan
el funcionamiento de los sistemas, pero es un error como dejar la puerta de casa abierta
para no perder tiempo en abrirla cuando lleguemos cargados con la compra, podemos
encontrarnos que puede ser muy tarde.
El coste de no saber qué pasa y quién ha accedido a qué puede ser mucho mayor que una
pequeña pérdida de rendimiento a causa de la seguridad.
171
20.5. Software seguro

En las empresas existe la costumbre de solicitar a sus proveedores de material las carac-
terísticas y especificaciones que han de cumplir, así una cadena de supermercados nos
dirá el tamaño de cada envío para poder almacenarlo, o una empresa de ropa nos dará los
parámetros de calidad de la tela.
De manera análoga, con los sistemas informáticos deberíamos hacer lo mismo, exigir
unos niveles razonables de seguridad, protección y calidad.
Así, cuando estemos adquiriendo un software a medida podremos y deberemos incluir

cláusulas estrictas que nos permitan garantizar la calidad del resultado y eliminar posi-
bles defectos posteriores.
Si, por el contrario, nos dedicamos al desarrollo del software, deberemos tener control
de que nuestros programadores sigan prácticas seguras de codificación y prueba de los
sistemas.
Un proveedor de bases de datos multinacional (no diremos el nombre) estima que poner
un parche importante (una corrección a problemas detectados) para su software le supo-
ne un millón de dólares. Sin embargo, ponen en circulación hasta una docena de parches
al mes. Sin embargo, se estima que si se quitara el error habitual de programación de
“desbordamiento de buffer” se podrían evitar hasta el 80% de ellos.
20.6. Conocer el software

Aunque el título puede parecer demasiado evidente, es una realidad que en muchas em-
presas no se controla el software que se utiliza, en muchos casos se conoce el software,
pero no la versión en la que se encuentra o qué parches se han aplicado.
Si no conocemos esa información, estamos expuestos a posibles agujeros de seguridad.

Las condiciones y configuraciones del software cambian constantemente, es posible que
sea necesaria una actualización, o cierto programa o aplicación no funcione con ella.
Por ello, es importante tener control y tener documentado con qué sistemas contamos,
en qué versión se encuentra cada uno de ellos y el motivo por el que no se encuentran a
la última versión si es que no lo están. Así como cualquier modificación que se realice y
cuándo y por quién se realiza la actualización.
De esta forma, si tenemos la información documentada, será más fácil identificar cual-
quier problema y conocer el estado. Un parche de seguridad no implementado puede ser
un agujero de seguridad explotado por un hacker o un intruso, por lo que es importante
conocer los parches existentes, así como justificar si no instalamos alguno porqué no se
instala y cómo nos protegemos contra la vulnerabilidad que corrige si es que la hay.
172
En muchos entornos se ha descubierto que la práctica de estar constantemente mejoran-

do nos sirve para detectar problemas en el entorno, atajarlos antes que nadie, así como
identificar la causa concreta que la produce.
Se da, en ocasiones, que la política de la compañía sea la aplicación de parches una vez al
año o cada seis meses, el inconveniente en esos casos es que un parche concreto puede
derivar en incompatibilidades si estamos instalando todos los parches aparecidos duran-
te ese periodo de tiempo en los distintos sistemas afectados, difícilmente detectaremos
quien es el causante de la incompatibilidad.
Es por tanto interesante mantenernos al día, pero de forma ordenada y controlada que nos
permita eludir cualquier problema dentro de un entorno.
20.7. Probar y comparar

Muchas veces, cuando queremos comenzar a implantar un plan de seguridad, el primer
paso que damos es realizar una exhaustiva auditoría de los sistemas para probar las de-
fensas de la empresa.
Esta práctica, aunque bienintencionada, es bastante inútil ya que nuestra empresa estará
expuesta. El asunto no es si lo está o no lo está, será determinar el grado de riesgo y qué
activos están en riesgo.
En muchos entornos se dice que no existe la seguridad absoluta y eso cuando habla-
mos de los sistemas informáticos se aplica completamente. Por lo que lo que debería de
preocuparnos sería más bien cuáles de nuestros sistemas están expuestos, qué programas
son accesibles y qué fácil es acceder a ellos y con todo esto preparar una respuesta.
Lo suyo es, por lo tanto, decidir qué sistemas estarán expuestos, qué información será
accesible, quién podrá acceder a esa información, y de qué manera podrán hacerlo.
Si los sistemas accesibles son de bajo interés para los incursores, lo más probable es que
busquen otros sistemas a los que acceder que sean más interesantes en cuanto a reto o a
los beneficios que les puedan generar.
Muchas veces tendemos a realizar múltiples auditorías para en base a ellas, establecer la
seguridad de nuestra empresa. En ocasiones descubrimos un problema, lo solucionamos
a través de la auditoría, pero no hemos llegado a la raíz del mismo.
Lo primero que deberíamos hacer, será establecer las correctas políticas, buscar cuáles
son las últimas tecnologías y novedades del sector, buscar las mejores prácticas y de
acuerdo a eso podremos realizar auditorías donde se compruebe el funcionamiento y se-
guimiento de las políticas.
173
Un elemento a garantizar es el entorno de replicación que podrá ser siguiendo recomen-

daciones estándares como:
1. CPD espejado en modo online, con un sistema clon al que está funcionando que ante
una caída de la web o ataque pueda levantar físicamente el servicio, independiente-
mente del ataque.
2. CPD en modo offline, replicándose el sistema en modo nocturno, por si el ataque

afecta también al sistema espejado.
3. Duplicidad en las líneas de datos: todas las líneas de datos deben estar clonadas, en
los tres CPD, la activa y una línea de backup.
4. Sistema de backup: sistema de backup con guardado de copias en cámara ignífuga

y de vacío.
20.8. Preparar respuestas

Cuando se produce una rotura en la seguridad, la organización entra en crisis y los direc-
tivos deben rápidamente tomar decisiones difíciles.
Si previamente hemos establecido procedimientos que ayuden al diagnostico del proble-

ma, que impidan la toma de respuestas de manera intuitiva y por lo tanto evitar proble-
mas de funcionamiento derivado de la toma de decisiones incorrectas, mejoraría notable-
mente el proceso de resolución de la crisis.
Otra de las cosas que podemos hacer es practicar las respuestas, ensayar lo que debemos
de hacer, por ejemplo, comprobar cuánto tiempo tardaríamos en recuperar la información
en caso de ataque o cuánto costaría recuperar todo el entorno.
Si realizamos una estrategia de respuestas y las ensayamos conseguiremos estar lo mejor

preparados posibles, por ejemplo:
1. Comprobación de que tipo de ataque se ha sufrido y posibles riesgos que haya podido
provocar el ataque.
2. Comprobar que el sistema espejado está funcionando correctamente.
3. En caso de que haya afectado al segundo sistema de seguridad, comprobar todas las
implicaciones.
4. No levantar el sistema off-line hasta que se haya comprobado el porqué del ataque y
las posibles pérdidas de información.
174
20.9. Analizar las causas

Siempre que descubramos un problema de seguridad en la empresa, deberíamos llevar a
cabo un análisis detallado para descubrir las causas que lo han permitido.
Los instrumentos necesarios son los mismos que se utilizarían para la comprobación de
sistemas de calidad, por ejemplo, Toyota sigue un método que denomina el método de
“Los cinco porqués” que le permite detectar los diferentes problemas en producción y
calidad, que lo mismo puede servir para detectar problemas informáticos.
Si lo usamos en el entorno informático las preguntas y respuestas pueden ser del tipo:
• ¿Por qué el firewall no detuvo la entrada no autorizada? Porque el atacante tenía

una contraseña que le permitía acceder al entorno.
• ¿Por qué el atacante tenía una contraseña de acceso? Porque un empleado de la

empresa le había revelado su contraseña a una persona que se había hecho pasar
por empleado del departamento de seguridad de la empresa.
• ¿Por qué reveló el empleado su contraseña? Porque no se dio cuenta que al revelar
la contraseña estaba poniendo en peligro la compañía.
• ¿Por qué no se dio cuenta del peligro? Porque no había leído el boletín de seguri-
dad de la compañía en donde se indicaba que no se debía de compartir esa infor-
mación con nadie.
• ¿Por qué no había leído el boletín de seguridad? Porque hubo un problema de dis-
tribución en el boletín y no llegó a todos los empleados de la empresa.
Tras años de haber utilizado ese método en Toyota descubrieron que utilizándolo conse-
guían ver cuál era la raíz del problema, incluso que la mayor parte de las veces el proble-
ma no tenía que ver con problemas tecnológicos o con fallos de las personas.
Se descubrió que la mayor parte de los problemas eran debido a fallos en el diseño y en el
propio proceso, por lo que la solución pasa por mejorar los procesos.
175

Cómo se crea y se desarrolla un plan de seguridad para una empresa dada, con los pasos
a seguir en la gestión de incidentes y como protegerse.
Dato importante
Es importante tener control y tener documentado con qué sistemas contamos, en

qué versión se encuentra cada uno de ellos y el motivo por el que no se encuentran
a la última versión si es que no lo están. Así como cualquier modificación que se
realice y cuándo y por quién se realiza la actualización.
176
21. Plan de seguridad

“Siempre que descubramos un problema de seguridad en la empre-
sa, deberemos llevar a cabo un análisis detallado para descubrir
las causas que lo han permitido.”
21.1. Escenario de competencia del gobierno electrónico

El gobierno electrónico “Es el uso de las TIC para promover un gobierno más eficiente y
efectivo en costos, facilitando servicios Gubernamentales más convenientes, permitiendo
un mayor acceso a la información y haciendo al gobierno más responsable con el ciudada-
no.” (Wescott, Pizarro, & Schiavo-Campo, 2001)
La OCDE1 define el gobierno electrónico como “El Uso de las TIC y, en particular, de
Internet, como herramienta para lograr un mejor gobierno […] que permite mejores resul-
tados políticos, servicios de mayor calidad y mayor compromiso con los ciudadanos […]
Las iniciativas de gobierno electrónico concentran la atención en una serie de cuestiones:
cómo colaborar más eficazmente entre las agencias para abordar problemas complejos y
compartidos; cómo mejorar el enfoque del cliente; y cómo establecer relaciones con socios
del sector privado.”
Wassenaar (2000), indica que “Desde una perspectiva de empresa, es la aplicación de las
TIC para mejorar, transformar o redefinir cualquier forma de intercambio de recursos e in-
formación entre compañías, agencias gubernamentales, ciudadanos, proveedores y otros
participantes, desarrollando y manteniendo sistemas interorganizacionales, organizacio-
nes virtuales y acuerdos interinstitucionales.”
A fin de cuentas, el gobierno electrónico es todo aquel uso o servicio que presta una ins-
titución gubernamental basada en tecnologías de información.
Las herramientas básicas que usan son Portales, GRP´s (que es el ERP´s enfocado a las
instituciones gubernamentales), redes sociales, CRM´s, etc.
El uso que se hace de estas aplicaciones, al igual que el uso que se podría hacer de es-
tas herramientas en cualquier institución privada, es la mejora de los procesos internos,
que sean más organizados, ayuden al correcto funcionamiento de la institución y den
servicios a los ciudadanos, empresarios e industrias tanto a nivel informativo como de
tramitación. A niveles de servicios el punto más importante es la web de la institución
gubernamental.
1 http://unpan1.un.org/intradoc/groups/public/documents/APCITY/UNPAN015120.pdf
177
21.1.1. Objetivos del Gobierno electrónico

Los principales objetivos que se asocian al gobierno electrónico son: Transparencia, ma-
nejo de uso y disponibilidad.
1. Transparencia: toda la información de la institución debe estar accesible al ciuda-

dano de una forma fácil y visible, de forma que los procesos y formas de trabajo de la
institución queden reflejados tanto en su documentación en papel, como telemática
y a través de su web. A nivel de transparencia el gobierno electrónico debe cubrir:
a. Gestión al acceso de contactos: cómo se deben hacer las gestiones y quién es la

persona responsable de ello dentro de la institución. Esto incluye la jerarquía de
la institución.
b. Gestión de la información: la institución gubernamental debe dejar latente que

es ella la que gestiona los contenidos y se ocupa de ellos. Y que cumpla con
todos los requisitos de la LOPD, a nivel de seguridad y de privacidad de la infor-
mación.
c. Gestión de los contenidos: los contenidos de la página web deben informar de lo

que se puede hacer en esta página web, de la información que contiene y de las
bases de uso de ellos.
d. Gestión de trámites: lo que puede hacer en la página web el ciudadano, las con-
secuencias de su uso y pasos que debe hacer el ciudadano para su correcto fun-
cionamiento.
2. Manejo de uso: el acceso a la diferente información y a los trámites que se puede

hacer de ellos, deben ser fáciles en su uso, y asequibles para el ciudadano. El uso de
la web debe ser fácil y claro.
a. Gestión de la seguridad y confidencialidad: el grado de formación que debe in-

troducir el ciudadano para realizar los trámites o acceder a la información debe
ser el mínimo e imprescindible en muchos casos. Para acceder a la información
con poner el DNI y el código postal debe bastar. Para acceso a determinados
trámites además necesitará o un certificado digital o una clave de acceso previa-
mente configurada por el ciudadano.
b. Gestión de la interactividad: la institución debe tener accesos para que el ciuda-

dano pueda realizar peticiones o ruegos.
c. Accesibilidad a la institución y contenidos: para cada trámite o para cada infor-

mación debe estar claro quién es la persona responsable y tener un fácil acceso
a la persona responsable. También debe mostrar los contenidos de cómo está
gestionando un determinado proceso o trámite.
178
a. Gestión de trámites y seguimiento de actividades: sencillez del trámite y fácil

seguimiento de las diferentes actividades.
1. Disponibilidad: la disponibilidad del sistema es uno de los objetivos fundamentales

del gobierno electrónico. La disponibilidad hace que el acceso de la información sea
inmediato y continuado.
21.2. Descripción y servicios de madrid.org

La página de información y servicios de la comunidad de Madrid es madrid.org. El mapa
de la web es muy amplio. En modo esquemático los contenidos que tiene madrid.org son:
Gobierno regional, Consejerías, Direcciones generales y otros centros directivos: Vi-

cepresidencia, Consejería de Cultura y Deporte y Portavocía del Gobierno, Consejería de
Presidencia y Justicia, Consejería de Economía y Hacienda, Consejería de Transportes
e Infraestructuras, Consejería de Educación y Empleo, Consejería de Medio Ambiente y
Ordenación del Territorio, Consejería de Sanidad, Consejería de Asuntos Sociales, Agen-
cia de Protección de Datos, Asamblea de Madrid, Consejo consultivo, Consejo Económico
Social, Cámara de Cuentas de Madrid.
Sede Electrónica: Sede Electrónica del Boletín Oficial de la Comunidad de Madrid
Atención al ciudadano: Formas de contacto y Direcciones, Portal de Atención al Ciuda-

dano, Teléfono 012, Red de Oficinas, Chat, Contactar con Atención al Ciudadano, Danos
tu opinión y Directorio temático de centros, direcciones y teléfonos.
Información por temas de interés: Asuntos Sociales, Atención al contribuyente, Becas,

ayudas y subvenciones, Consumo, Cultura, Deporte, Educación, Empleo, Estadística, Jus-
ticia, Medio Ambiente, Promoción de la actividad económica y empresarial, Servicios a la
ciudadanía y Protección ciudadana, Salud, Transportes, Turismo, Vivienda y Urbanismo.
Normativa y boletín oficial de la comunidad de Madrid: Boletín Oficial, Legislación de

la Comunidad de Madrid, Normativa por Consejerías.
Subscripción: Mi Madrid.
Portales. Otras páginas Web de la comunidad de Madrid con información más especí-
fica: Elecciones Asamblea de Madrid 2015, Presidencia, Sanidad, Salud, Madrid, Hospita-
les, Transportes de Madrid, Portal del Mayor, Portal de Educación, Portal del Consumidor,
Portal de Vivienda, Infojoven, Portal de la Accesibilidad, Portal del Deporte, Relaciones
con Inversores, Portal del Contribuyente, Portal de la Contratación Pública, Madrid Puer-
ta de Europa, Portal de Empleo, Inmigramadrid, Madrileños en el exterior, Emprendedor,
Información Estadística, Visor cartográfico PLANEA, Museos.
Acceso a otros servicios: Rss, Redes sociales, Opine, Contactar y Videoteca.
179
21.3. Objetivos del plan

El gobierno electrónico es muy amplio, por lo que el alcance y al mismo tiempo objetivo
del plan es crear un plan de seguridad a alto nivel, englobando los ámbitos más impor-
tantes.
El plan de seguridad que se va a desarrollar, está enfocado a la protección, correcto fun-

cionamiento y la disponibilidad de la página web www.madrid.org, pagina de información
y servicios de la comunidad de Madrid.
Se revisarán las principales amenazas, análisis del riesgo, política de seguridad y plan de
continuidad, centrándose en la confidencialidad, disponibilidad, autenticidad, trazabili-
dad y autenticidad.
En este documento no se procederá a explicar el punto de identificación de activos, ya que

al ser generalizado a un sector es complicado medir el grado de magnitud de este punto.
21.4. Principales amenazas

El análisis de amenazas es algo que en principio debe realizarse para cada uno de los
activos involucrados dentro del entorno, pero al estar analizando un sector, veremos los
diferentes tipos de amenazas que podamos tener dentro del entorno y cómo podríamos
combatirlas.
Viendo las amenazas que pueden llegar por tanto en el entorno del gobierno electrónico
serían de tipos:
• Confidencialidad: garantizar que la información esté llegando solo, única y exclu-

sivamente a la persona interesada.
• Integridad: garantía de que los datos son completos y exactos de punto a punto.
• Disponibilidad: que se pueden usar cuando sea necesario.
• Autenticidad: garantía de que los datos sean verídicos.
• Trazabilidad: garantizar que se puede seguir la información desde su origen hasta

su entrega.
Dentro de cada uno de estas grandes amenazas para todos los activos, habrá que evaluar
cada una en mayor profundidad.
180
21.4.1. Confidencialidad
Cuando nos encontramos en un entorno de gobierno electrónico, como puede ser el caso
de madrid.org, tenemos gran cantidad de trámites que se pueden realizar a través de la
web como aportación de documentos, solicitud de cita previa para la sanidad o pagos de
tasas o impuestos, un elemento clave en el envío y recepción de toda la documentación
necesaria, así como nuestros pagos o la recepción de los mismos es proteger al ciuda-
dano y permitir garantizar que los datos que entrega a la Administración van a quedar
restringidos al ámbito necesario y que nadie que no tenga la obligatoriedad de acceder a
ellos va a poder hacerlo, así mismo se debe de garantizar que la conexiones son seguras y
completas dentro del entorno.
21.4.2. Integridad
En el momento en que en una herramienta de gobierno electrónico como es el caso de
madrid.org entran en función intercambio de información y/o documentación entre la
Administración Pública y el interesado/ciudadano, la Administración debe poner todos
los medios para garantizar que en ese intercambio de información los datos se puedan
enviar íntegramente y los datos recibidos sean exactamente los enviados, sin pérdida de
información por el camino que pueda dar lugar a error, o problemas posteriores como
pudiera ser una multa por algún dato que no se tenía de partida.
21.4.3. Disponibilidad
Cuando acudimos a herramientas de gobierno online, lo que se presupone y lo que se bus-
ca es una herramienta que esté operativa en todo momento y a la que podamos recurrir, la
web funciona 24/7 y, por lo tanto, hemos de garantizar que cualquier ciudadano que quie-
ra acceder a los portales bien para informarse, bien para realizar trámites, los encuentre
disponibles y pueda realizar lo que desee siempre que sea en el plazo establecido.
Tan importante como poder garantizar los datos es poder dar la garantía de su validez,
hemos de proveer los recursos necesarios para evitar que el propio portal sea suplantado,
permitiendo recibir información a alguien que es la persona indebida, como también se
debe de garantizar que los datos recibidos son enviados por la persona que dice ser, y no
que alguien aprovechándose de las nuevas tecnologías pueda suplantar a la persona que
se encuentra al otro lado del terminal.
181
21.4.5. Trazabilidad
Aunque en muchas ocasiones, no lo consideraríamos propiamente una amenaza, lo que sí
permite es ofrecer una garantía para que los datos tratados se puedan considerar comple-
tamente válidos, poder hacer un seguimiento de por donde han llegado, que medios se ha
seguido y que eso nos permita hacer una garantía de Integridad y Autenticidad.
21.5. Análisis del riesgo

Tendremos que evaluar cuál es el nivel de riesgo que se produce para cada uno de los
activos de acuerdo a las amenazas con las que nos podemos encontrar, por ello, nueva-
mente analizaremos cada una de las distintas amenazas y evaluaremos como pueden ser
atacadas o como se pueden producir variaciones en el servicio.
21.5.1. Confidencialidad
Si no somos capaces de controlar la confidencialidad de los datos, podemos estar incu-
rriendo en una serie de faltas, comenzando por las multas a las que incurriríamos por el
incumplimiento de la LOPD, en el caso del gobierno electrónico, hablamos del acceso a
través de herramientas electrónicas o herramientas remotas a nuestros datos, en ocasio-
nes datos de alta sensibilidad como podría ser en el caso de solicitar un cita previa para
un entorno médico, por lo que incluso estaríamos incurriendo en la gestión de datos de
alta sensibilidad.
Los problemas para la confidencialidad pueden venir o bien por no almacenarlos en un

entorno adecuadamente seguro, o no proteger el canal de comunicación.
Así mismo, al estar gestionando o manejando datos sensibles de los usuarios, hemos de
tener cuidado en la definición del fichero de datos que realizaremos en la AEPD.
Por lo tanto, hemos de atender tanto al canal de comunicación como al almacén de los
datos a la hora de establecer nuestras políticas de seguridad para garantizar la confiden-
cialidad, evaluando el grado de eficiencia de las políticas existentes y si el riesgo en el
que incurrimos para cada uno de los activos implicados daría un impacto residual o per-
manente en la confidencialidad de los datos, no es lo mismo una BBDD accesible, que un
canal poco securizado o que pueda ser atacado.
182
21.5.2. Integridad
En el caso de las garantías de la integridad, el no tener los datos completos y reales de
un ciudadano, o el no ofrecer al mismo datos no válidos, son los riesgos frente a los que
ha de asegurarse en la gestión del gobierno electrónico, ambos casos pueden ser igual-
mente perjudiciales, bien porque la Administración no sea capaz de ejecutar las acciones
necesarias de acuerdo a la información recogida de un individuo, bien porque la ausencia
de datos puede acarrear problemas para el ciudadano como el no recibir la información
adecuada o incurrir en multas indebidas.
21.5.3. Disponibilidad
Si se ofrece una plataforma de interacción entre los ciudadanos y la Administración, la
Administración ha de garantizar que esta esté siempre accesible, bien para la consulta de
información, bien para la realización de trámites, como cualquier entorno web está sujeto
a ataques, como denegación de servicio o eliminación de la posibilidad de acceder por
modificación en los DNS. Por lo tanto, la Administración ha de poner los medios para
garantizar el funcionamiento del canal en todo momento, evitando que ningún ciudadano
que desee realizar alguna interacción con la Administración no pueda realizarlo.
En el uso y existencia de un canal de comunicación entre la Administración y los ciuda-
danos, uno de los mayores peligros e inconvenientes a los que se puede enfrentar es la
posibilidad o el miedo que puedan tener los ciudadanos a que la página a la que se accede
pueda ser lo que se conoce como un fake una suplantación de la página web de la Admi-
nistración (tipo de ataque que se realiza mediante la sustitución del camino en los DNS
mundiales).
Otro gran riesgo del que se debe proteger es la posibilidad de que el ciudadano que ac-
cede a los sistemas electrónicos para realizar el trámite, sea realmente quien dice ser, y
no trate de acceder a información de otros posibles usuarios haciéndose pasar por otra
persona, es decir suplantando su identidad. Para poder evitar esto, se han de poner los
medios como proteger la comunicación con certificados o en el caso de cualquier Admi-
nistración española, con el DNI-e.
183
21.5.5. Trazabilidad
Al plantear la Administración la existencia de portales de gobierno electrónico, como me-
dios de información e intercambio de información entre los usuarios y la Administración,
esta ha de garantizar y proporcionar los medios que permitan autentificar los datos entre-
gados desde dónde se han entregado y por quién ya que eso puede ayudar en cualquier
caso de los anteriores, a garantizar la autenticidad o la veracidad de los datos con los que
se trabaja, para ello debe quedar registrados junto con el documento todos los metadatos
asociados a él, de dónde, cuándo, por quién, por qué medio se ha realizado la entrega, etc.
21.6. Políticas de seguridad

Las políticas de seguridad en el gobierno electrónico en España y por supuesto aplicable
a madrid.org vienen determinadas por el Centro criptológico nacional, por la metodolo-
gía MARGERIT V2 y el esquema nacional de seguridad que viene determinado por la
herramienta PILAR.
El centro criptológico nacional cubre los siguientes puntos, con la serie CCN-STIC (Nor-
mas del centro criptológico nacional para seguridad de tecnología de información y co-
municaciones):
• 000 Políticas
• 100 Procedimientos
• 200 Normas
• 300 Instrucciones técnicas
• 400 Guías generales
• 500 Guías Windows
• 600 Guías otros entornos
• 800 Esquema Nacional de Seguridad
• 900 Informes técnicos.
184
El desglose de todas las normas de seguridad para cada uno de los diferentes entornos
aparece detallado en el ANEXO I.
El centro criptológico nacional marca dos normas fundamentales que afectarán a www.
madrid.org:
• CCN-STIC-001 Seguridad de las TIC en la Administración
• CCN-STIC-412 Requisitos de Seguridad de Entornos y Aplicaciones Web.
La política de seguridad está para entornos web como www.madrid.org debe contener:
• Programación en aplicaciones web.
• Protocolos web.
• Herramientas de análisis y manipulación web.
• Ataques sobre entornos web.
• Mecanismos de autenticación y autorización web.
• Gestión de sesiones.
21.6.1. Programación en aplicaciones web

La mayor vulnerabilidad de las aplicaciones web, vienen dadas por errores en escritura
del código. La estructura de programación de aplicaciones web esta detallada en la CCN-
STIC-412, a rasgos generales se debe cumplir:
• No habilitar parámetros de ocultación de origen de datos: contribuye a la pér-

dida de control por parte del programador sobre los procesos de cada variable del
programa.
• Deshabilitar mensajes de error enviado por el servidor: cuando el aplicativo

web pasa a producción se debe deshabilitar los mensajes de error enviados por el
servidor ya que puede ser usado por el atacante, para sacar información útil de la
web.
• Balancear riesgo y usabilidad: las medidas de seguridad deben ser transparentes

para el usuario y que no afecten a la usabilidad. Petición de usuarios y contraseñas
para el usuario es aceptable y lógico.
185
• Rastreo el paso de los datos: se deben conocer en todo momento desde dónde
están entrando los datos, a dónde van y de dónde están saliendo.
• Filtrado de entradas: comprobación de la validez de datos que se están introdu-

ciendo. Con estas comprobaciones se eliminarán la posible entrada de datos com-
binados.
• Control de fugas de datos: codificación o descodificación con caracteres para pre-

servar el significado original de la información.
Con una correcta programación minimizamos los riesgos de confidencialidad, integridad,

autenticidad y trazabilidad.
21.6.2. Protocolos web

Los protocolos web del gobierno electrónico están totalmente protegidos y detallados en
las normas anteriormente citadas especialmente en la norma CCN-STIC-412.
Con los protocolos web se minimiza el riesgo de disponibilidad.
21.6.3. Herramientas de análisis y manipulación web

El gobierno electrónico como herramientas de análisis recomienda el uso de la herra-
mienta PILAR, para el análisis y monitorización de correcto funcionamiento de la página
web.
Con las herramientas de análisis y manipulación web se minimiza el riego de confiden-

cialidad, integridad, autenticidad y disponibilidad.
21.6.4. Ataques sobre entornos web

Los ataques de entorno web más típicos determinados por la CCN-STIC-412 son: Inyec-
ción SQL, Cross-Site Scripting (XSS) y Cross-SiteRequestForgery (CSRF).
Protegerse adecuadamente contra estos ataques lleva a protegerse contra los riegos de
confidencialidad, integridad, autenticidad, trazabilidad y disponibilidad.
21.6.4.1. Inyección SQL

La inyección de SQL es debida a: un fallo por el filtrado de datos y fallos en el control
de fuga de datos. Son fácilmente evitables controlando el filtrado de datos y los posibles
fallos en el filtrado de datos.
186
21.6.4.2. Cross-Site Scripting (XSS)

Permite la inyección de código por usuarios maliciosos en las páginas web que ven los
usuarios. Con este tipo de ataque se puede burlar los controles de acceso. Cuando un
usuario tiene abierta varias páginas en su navegador, un sript de una página puede permi-
tir acceder a los datos de las otras páginas, habiendo un agujero en la seguridad.
21.6.4.3. Cross-Site Request Forgery (CSRF).

El usuario malicioso puede lanzar ataques desde la máquina del usuario. Este tipo de ata-
ques se realizan al introducir el código malicioso en una imagen.
21.6.5. Mecanismos de autenticación y autorización web

La autentificación es el proceso por lo que un usuario se valida en la página de la institu-
ción como www.madrid.org. Previamente, el usuario ha debido solicitar el alta en la web y
la institución ha debido comprobar previamente la validez de los datos, con lo que se evi-
ta la introducción de datos combinados, una vez validados al usuario se le da un usuario
y contraseña con cifrado seguro.
Mecanismos correctos de autentificación y autorización lleva a protegerse contra los rie-

gos de confidencialidad, autenticidad y trazabilidad.
21.6.6. Gestión de sesiones

La web y el sistema debe controlar que los usuarios solo puedan abrir una sesión al mis-
mo tiempo, esto prevé posibles usurpaciones de la identidad.
La gestión de sesiones minimiza los riesgos de: confidencialidad e integridad, autenti-

cidad.
La gestión de back up y los planes de continuidad se explican a continuación.
21.6.7. Gestión del entorno físico

La gestión del entorno físico nos proveerá también de una seguridad dentro del entorno
añadida, uno de los principales puntos de caída y fallo de los entornos se suele dar por la
interacción de las personas, por lo tanto, proteger que solo aquellos operadores autoriza-
dos puedan llegar a las maquinas, así como mantener constancia de quién, y cuándo ac-
cede al entorno, cerrando el CPD con tarjeta magnética y manteniendo un log de accesos.
Para apoyar esta seguridad, los accesos al edificio deben de estar controlados, evitando el
acceso con material indebido como portátiles o llaves USB que pudieran utilizarse bien
para introducir software malicioso bien para llevarse información, atacando a la integri-
dad, disponibilidad o trazabilidad de los datos.
187
21.7. Plan de continuidad del negocio

Plan de continuidad para el gobierno electrónico para www.madrid.org contiene los si-
guientes puntos:
5. Coste de oportunidad de la interrupción del servicio.
6. Identificación de elementos críticos.
7. Incorporación equipamiento de respaldo.
8. Estimación del impacto y riesgo residuales
9. Diseño plan de recuperación.
21.7.1. Coste de oportunidad de interrupción de servicio

La página www.madrid.org contiene servicios muy sensibles para el ciudadano, tal y como
indica el punto 2, servicios como firma del paro o servicios de pago de impuestos, hace
que la página web sea muy sensible a interrupciones.
La parada de la página puede significar pérdida económica ya del ciudadano, sirva a

modo de ejemplo el retraso de un pago debido a indisponibilidad de la página o no poder
firmar el paro que con lleva un mes de sanación de pago. Considerando estos servicios la
disponibilidad de la página debe ser un 99,99% y se debe establecer los planes de conti-
nuidad que se cumpla esta disponibilidad.
21.7.2. Identificación de elementos críticos

Los elementos críticos para mantener una disponibilidad del 99,99% son:
1. Mantenimiento y seguridad de los backups.
2. Sistema espejado en CPD diferentes, con un tercer sistema off-line.
3. Duplicidad de líneas de comunicación.
4. Test de continuidad.
Dato importante
La mayor vulnerabilidad de las aplicaciones web, vienen dadas por errores en es-
critura del código.
188
21.7.3. Incorporación equipamiento de respaldo

Como se ha comentado en el punto anterior, el equipamiento de respaldo, debe tener
contemplado los siguientes sistemas:
1. CPD espejado en modo online, con un sistema clon al que está funcionando que ante
una caída de la web o ataque pueda levantar físicamente el servicio, independiente-
mente del ataque.
2. CPD en modo offline, replicándose el sistema en modo nocturno, por si el ataque

afecta también al sistema espejado.
3. Duplicidad en las líneas de datos: Todas las líneas de datos deben estar clonadas, en
los tres CPD, la activa y una línea de Backup.
4. Sistema de backup: sistema de backup con guardado de copias en cámara ignifuga

y de vacío.
21.7.4. Estimación del impacto y riesgo residuales

El impacto de una posible caída deberá ser mínimo con los sistemas anteriormente co-
mentados, como riesgo residual puede quedar una pequeña parada si el ataque llega a
afecta al sistema espejado una parada máxima de 4 horas para levantar el sistema off-line.
21.7.5. Diseño del plan de recuperación

El plan de recuperación está diseñado para que sea totalmente online y automatizado
dependiendo al tipo de ataque que se haya dado, pero los pasos a seguir en caso de caída,
es el siguiente:
1. Comprobación de que tipo de ataque se ha sufrido y posibles riesgos que haya podido
provocar el ataque.
2. Comprobar que el sistema espejado está funcionando correctamente.
3. En caso de que haya afectado al segundo sistema de seguridad, comprobar todas las
implicaciones.
4. No levantar el sistema off-line hasta que se haya comprobado el porqué del ataque y
las posibles pérdidas de información.
189
21.8. Conclusiones
En todo el documento se ha intentado plasmar, a grandes rasgos un plan de seguridad
para una Web que tenga gobierno electrónico: www.madrid.org. El gobierno electrónico
es muy amplio y abarca un ámbito muy dado a posibles ataques, con lo que los sistemas
de seguridad empleados por el gobierno están altamente protegidos y confidenciales.
21.9. Anexo
000 Políticas
La Serie CCN-STIC-000 constituye el conjunto de normas que desarrolla el Real Decreto

421/2004, de 12 de marzo, por el que se regula el Centro Criptológico Nacional.
• CCN-STIC-001 Seguridad de las TIC en la Administración.
• CCN-STIC-002 Coordinación Criptológica.
• CCN-STIC-003 Uso de Cifradores Certificados.
100 Procedimientos
La Serie CCN-STIC-100 establece el marco común de actuación en los procesos de acre-

ditación, certificación TEMPEST, gestión de material de cifra y de cualquier otro campo
que se considere.
• CCN-STIC-101 Procedimiento de Acreditación Nacional.
• CCN-STIC-103 Catálogo de Productos Certificados.
• CCN-STIC-150 Evaluación y Clasificación TEMPEST de Cifradores con Certifica-

ción Criptológica.
• CCN-STIC-151 Evaluación y Clasificación TEMPEST de Equipos.
• CCN-STIC-152 Evaluación y Clasificación Zoning Locales.
• CCN-STIC-153 Evaluación y Clasificación de Armarios Apantallados.
190
200 Normas
La Serie CCN-STIC-200 comprende reglas generales que deben seguirse, o a las que se
deben ajustar las conductas tareas o actividades de las personas y Organizaciones, en
relación con la protección de la información cuando es manejada por un Sistema.
• CCN-STIC-201 Estructura de Seguridad.
• CCN-STIC-202 Estructura y Contenido DRS.
• CCN-STIC-203 Estructura y Contenido POS.
• CCN-STIC-204 CO-DRS-POS Pequeñas Redes.
• CCN-STIC-205 Actividades Seguridad Ciclo Vida CIS.
• CCN-STIC-207 Estructura y Contenido del Concepto Operación.
300 Instrucciones técnicas
Las Serie CCN-STIC-300 atiende a un objetivo de seguridad específico, y será eminen-

temente técnica, estableciendo los requisitos de seguridad generales a implantar en un
Sistema y sus interconexiones asociadas.
• CCN-STIC-301 Requisitos STIC.
• CCN-STIC-302 Interconexión de CIS.
• CCN-STIC-303 Inspección STIC.
• CCN-STIC-307 Seguridad en Sistemas Multifunción.
400 Guías generales
La Serie CCN-STIC-400 incluye recomendaciones para los responsables de seguridad

relativas a aspectos concretos de la seguridad de las TIC (seguridad perimetral, redes
inalámbricas, telefonía móvil, herramientas de seguridad, etc.)
• CCN-STIC-400 Manual STIC.
• CCN-STIC-401 Glosario / Abreviaturas (Acceso Público).
• CCN-STIC-402 Organización y Gestión TIC.
• CCN-STIC-403 Gestión Incidentes de Seguridad.
• CCN-STIC-404 Control de Soportes Informáticos.
191
• CCN-STIC-405 Algoritmos y Parámetros de Firma Electrónica.
• CCN-STIC-406 Seguridad Redes Inalámbricas.
• CCN-STIC-407 Seguridad Telefonía Móvil.
• CCN-STIC-408 Seguridad Perimetral – Cortafuegos.
• CCN-STIC-409 Colocación Etiquetas de Seguridad.
• CCN-STIC-410 Análisis de Riesgos de Administración.
• CCN-STIC-411 Modelo Plan de Verificación STIC.
• CCN-STIC-412 Requisitos de Seguridad de Entornos y Aplicaciones Web.
• CCN-STIC-414 Seguridad en Voz sobre IP.
• CCN-STIC-415 Identificación y Autenticación Electrónica.
• CCN-STIC-416 Seguridad en VPN`s.
• CCN-STIC-418 Seguridad en Bluetooth.
• CCN-STIC-419 Configuración segura con Iptables.
• CCN-STIC-430 Herramientas de Seguridad.
• CCN-STIC-431 Herramientas de Análisis de Vulnerabilidades.
• CCN-STIC-432 Seguridad Perimetral – IDS.
• CCN-STIC-434 Herramientas para el Análisis de ficheros de logs.
• CCN-STIC-435 Herramientas de Monitorización de Tráfico.
• CCN-STIC-436 Herramientas de Análisis de Contraseñas.
• CCN-STIC-437 Herramientas de Cifrado Software.
• CCN-STIC-438 Esteganografía.
• CCN-STIC-440 Mensajería Instantánea.
• CCN-STIC-441 Configuración Segura de VMWare.
• CCN-STIC-443 RFID.
192
• CCN-STIC-470A Manual de la herramienta de análisis de riesgos PILAR v.4.1.
• CCN-STIC-470B Manual de la herramienta de análisis de riesgos PILAR v.4.3.
• CCN-STIC-470C Manual de la herramienta de análisis de riesgos PILAR v.4.4.
• CCN-STIC-471B Manual de ayuda de RMAT.
• CCN-STIC-472A Manual de la herramienta de análisis de riesgos PILAR BASIC

v.4.3.
• CCN-STIC-472B Manual de la herramienta de análisis de riesgos PILAR BASIC

v.4.4.
• CCN-STIC-480 Seguridad en sistemas SCADA.
• CCN-STIC-480A SCADA - Guía de buenas prácticas.
• CCN-STIC-480B SCADA - Comprender el riesgo del negocio.
• CCN-STIC-480C SCADA - Implementar una arquitectura segura.
• CCN-STIC-480D SCADA - Establecer capacidades de respuesta.
• CCN-STIC-480E SCADA - Mejorar la concienciación y las habilidades.
• CCN-STIC-480F SCADA - Gestionar el riesgo de terceros.
• CCN-STIC-480G SCADA - Afrontar proyectos.
• CCN-STIC-480H SCADA - Establecer una dirección permanente.
• CCN-STIC-490 Dispositivos biométricos de huella dactilar.
• CCN-STIC-491 Dispositivos biométricos de iris.
500 Guías Windows
La Serie CCN-STIC-500 es un conjunto de normas desarrolladas para entornos basados

en el sistema operativo Windows de Microsoft siendo de aplicación para la Administra-
ción y de obligado cumplimiento para los Sistemas que manejen información clasificada
nacional. Esta serie se ha diseñado de manera incremental de tal forma que dependiendo
del Sistema se aplicarán consecutivamente varias de estas guías
• CCN-STIC-501A Seguridad en Windows XP SP2 (cliente en dominio).
• CCN-STIC-501B Seguridad en Windows XP SP2 (cliente independiente).
193
• CCN-STIC-502 Seguridad para aplicaciones cliente Windows. Navegador y correo

electrónico.
• CCN-STIC-502B Seguridad para navegador y correo electrónico en Windows Vis-

ta.
• CCN-STIC-503A Seguridad en Windows 2003 Server (controlador de dominio).
• CCN-STIC-503B Seguridad en Windows 2003 Server (servidor independiente).
• CCN-STIC-504 Seguridad en Internet Information Server.
• CCN-STIC-505 Seguridad en BD SQL 2000.
• CCN-STIC-506 Seguridad en MS EXCHANGE Server 2003.
• CCN-STIC-507 Seguridad ISA Server.
• CCN-STIC-508 Seguridad en clientes W2000.
• CCN-STIC-509 Seguridad en Windows 2003 Server. Servidor de ficheros.
• CCN-STIC-510 Seguridad en Windows 2003 Server. Servidor de impresión.
• CCN-STIC-512 Gestión de actualizaciones de seguridad en sistemas Windows.
• CCN-STIC-517A Seguridad en Windows Vista (cliente en dominio).
• CCN-STIC-517B Seguridad en Windows Vista (cliente independiente).
• CCN-STIC-519A Seguridad para aplicaciones cliente Windows XP. Navegador y

correo electrónico.
• CCN-STIC-521A Seguridad entorno Windows 2008 (DC y Miembro).
• CCN-STIC-521B Seguridad entorno Windows 2008 (Independiente).
• CCN-STIC-522B Configuración Segura Windows 7 Enterprise (Independiente).
600 Guías otros entornos
La Serie CCN-STIC-600 es un conjunto de guías que tienen por objeto facilitar la apli-
cación de seguridad en distintas tecnologías que normalmente proporcionan servicios
básicos en los Sistemas de la Administración. Estas guías establecerán las configuracio-
nes mínimas de seguridad de tecnologías basadas en: HP-UX, SUN SOLARIS, LINUX,
Equipos de Comunicaciones, etc.
194
• CCN-STIC-601 Seguridad HP-UX 10.20.
• CCN-STIC-602 Seguridad HP-UX 11i.
• CCN-STIC-610 Seguridad Red Hat Linux 7.
• CCN-STIC-611 Seguridad SuSE Linux.
• CCN-STIC-612 Seguridad Debian.
• CCN-STIC-614 Seguridad Red Hat Linux (FEDORA).
• CCN-STIC-621 Seguridad Sun Solaris 8.0.
• CCN-STIC-622 Seguridad Sun Solaris 9.0 para Oracle 8.1.7.
• CCN-STIC-623 Seguridad Sun Solaris 9.0 para Oracle 9.1.
• CCN-STIC-624 Seguridad Sun Solaris 9.0 para Oracle 9.2.
• CCN-STIC-625 Seguridad Sun Solaris 9.0 para Oracle 10g.
• CCN-STIC-626 Guía de Securización de Sun Solaris 10 con NFS.
• CCN-STIC-627 Guía de Securización de Sun Solaris 9 con Workstation.
• CCN-STIC-628 Guía de Securización de Sun Solaris 9 con NFS.
• CCN-STIC-629 Guía de Securización de Sun Solaris 10 con Workstation.
• CCN-STIC-631 Seguridad en BD Oracle 8.1.7 sobre Solaris.
• CCN-STIC-633 Seguridad en BD Oracle 9i sobre Red Hat 3 y 4.
• CCN-STIC-634 Seguridad en BD Oracle 9i sobre Solaris 9 y 10.
• CCN-STIC-635 Seguridad en BD Oracle 9i sobre HP-UX 11i.
• CCN-STIC-636 Seguridad en BD Oracle 10gR2 sobre Red Hat 3 y 4.
• CCN-STIC-637 Seguridad en BD Oracle 10gR2 sobre Solaris 9 y 10.
• CCN-STIC-638 Seguridad en BD Oracle 10gR2 sobre HP-UX 11i.
• CCN-STIC-639 Seguridad en BD Oracle 10gR2 sobre Windows 2003.
• CCN-STIC-641 Seguridad en Eq. Comunicaciones. Routers de CISCO.
195
• CCN-STIC-642 Seguridad en Eq. Comunicaciones. Switches ENTERASYS.
• CCN-STIC-644 Seguridad en Eq. Comunicaciones. Switches CISCO.
• CCN-STIC-655 Guía de Securización para Sun Solaris 9 con Oracle 10.
• CCN-STIC-656 Guía de Securización para Sun Solaris 9 con Oracle 10 y VCS 4.1.
• CCN-STIC-671 Seguridad de Servidor Web Apache.
• CCN-STIC-672 Seguridad de Servidor WEB TOMCAT.
• CCN-STIC-681 Seguridad de Servidor Correo Postfix.
• CCN-STIC-682 Seguridad de Servidor Correo Senmail.
• CCN-STIC-691 Oracle Application Server 10gR2 para Red Hat 3 y 4.
• CCN-STIC-692 Oracle Application Server 10gR2 para Solaris 9 y 10.
• CCN-STIC-693 Oracle Application Server 10gR2 para HP-UX 11i.
800 Esquema Nacional de Seguridad
La Serie CCN-STIC-800 establece las políticas y procedimientos adecuados para la im-

plementación de las medidas contempladas en el Esquema Nacional de Seguridad (RD
3/2010).
• CCN-STIC-800 Glosario de Términos y Abreviaturas del Esquema Nacional de

Seguridad.
• CCN-STIC-801 Responsabilidades en el Esquema Nacional de Seguridad (BO-

RRADOR).
• CCN-STIC-802 Auditoría del Esquema Nacional de Seguridad.
• CCN-STIC-803 Valoración de sistemas en el Esquema Nacional de Seguridad (BO-

RRADOR).
• CCN-STIC-804 Medidas de implantación del Esquema Nacional de Seguridad

(BORRADOR).
• CCN-STIC-805 Política de seguridad del Esquema Nacional de Seguridad (BO-

RRADOR).
• CCN-STIC-806 Plan de Adecuación del Esquema Nacional de Seguridad (BORRA-

DOR).
196
• CCN-STIC-807 Criptología de empleo en el Esquema Nacional de Seguridad (BO-

RRADOR).
• CCN-STIC-808 Verificación del cumplimiento de las medidas en el Esquema Na-

cional de Seguridad (BORRADOR).
• CCN-STIC-809 Declaración de Conformidad del Esquema Nacional de Seguridad

(BORRADOR).
900 Informes técnicos
La Serie CCN-STIC-900 contiene documentos de carácter técnico que recogen el resulta-

do y las conclusiones de un estudio o evaluación teniendo por objeto facilitar el empleo
de algún producto o aplicación de seguridad.
• CCN-STIC-903 Configuración Segura HP IPAQ.
• CCN-STIC-951 Recomendaciones empleo Herramienta Ethereal.
• CCN-STIC-952 Recomendaciones empleo Herramienta Nessus.
• CCN-STIC-953 Recomendaciones empleo Herramienta Snort.
• CCN-STIC-954 Recomendaciones empleo Herramienta NMAP.
• CCN-STIC-955 Recomendaciones empleo GnuPG.
• CCN-STIC-956 Entornos virtuales.
• CCN-STIC-970 Interconexión CIS mediante cifradores IP a través de redes públi-

cas.

Una aplicación práctica de un plan de seguridad en un entorno de Gobierno electrónico.
Dato importante
Las políticas de seguridad en el gobierno electrónico en España, vienen determi-

nadas por el Centro criptológico nacional, por la metodología MARGERIT V2 y el
esquema nacional de seguridad que viene determinado por la herramienta PILAR.
197
22. Gestión del riesgo

“La gestión del riesgo forma parte integrante de todas las activi-
dades de gestión de seguridad de la información y debe aplicar-
se tanto en la implantación inicial como en la operativa de mejora
continua de un entorno informático mediante un proceso continuo
de revisión y adaptación al contexto dinámico de la organización.”
22.1. Términos y definiciones

El estándar ISO/IEC 27001:2005 proporciona algunos de los términos fundamentales
para una buena comprensión del texto del estándar.
La publicación de ISO/IEC 27005:2008 amplía el número de definiciones en relación a la

gestión de los riesgos, así como su extensión en algunas de ellas, con el objeto de aportar
una mayor claridad en el uso de las mismas e interpretación de los estándares de la serie
27000.
22.2. La gestión del riesgo
22.2.1. Tipos de metodología de análisis de riesgo

El análisis de riesgos puede realizarse en diversos niveles de detalle dependiendo de la
criticidad de los activos, la extensión de las vulnerabilidades conocidas y el grado de in-
formación previa sobre los incidentes que hayan acontecido en la organización.
Las estimaciones utilizadas en una metodología pueden ser cualitativas, cuantitativas o

una combinación de ambas dependiendo de la opción seleccionada.
Como referencia inicial, la estimación cualitativa es a menudo utilizada en un primer mo-

mento para obtener una indicación general del nivel de riesgo y desvelar los principales
riesgos.
198
A partir de esta primera experiencia en el proceso de estimación, puede ser necesario

realizar un análisis más específico sobre los principales riesgos tendiendo a estimaciones
cuantitativas o una mezcla de ambas.
En este proceso de cambio en las estimaciones, hay que tener en cuenta el coste adicional
de recursos dedicados a las estimaciones ya que suele ser menos complejo y menos cos-
toso llevar a cabo estimaciones cualitativas que cuantitativas.
En cualquiera de los dos tipos de estimaciones, o mediante una combinación de ambas, el

tipo de análisis debe ser coherente con los criterios de evaluación del riesgo establecidos
por la metodología y comprensible para todos aquellos que participen en las valoraciones
para que los resultados sean adecuados a los requisitos del SGSI, a las necesidades de la
organización y a los requisitos legales y reglamentarios.
Otro punto clave a considerar dentro de los requisitos del estándar ISO/IEC 27001 (cláu-
sula 4.2.1 c) es que la metodología de evaluación del riesgo seleccionada asegure que las
evaluaciones del riesgo producen resultados comparables y reproducibles.
A continuación, se detallan los tipos de metodologías de estimación mencionadas.
22.2.1.1. Metodologías cualitativas

Aquellas metodologías que desarrollan estimaciones cualitativas utilizan una escala de
calificación de atributos para describir la magnitud de las posibles consecuencias (por
ejemplo, “baja”, “media” y “alta”) y la probabilidad de que esas consecuencias se produz-
can.
Una de las ventajas principales de la estimación cualitativa es su facilidad de compren-

sión por parte de todo el personal pertinente que participa en las estimaciones al ser una
mecánica de asignación de magnitudes sobradamente conocida.
En este mismo sentido, la desventaja principal es la dependencia de la elección subjetiva

entre las magnitudes de la escala, que puede ser excesivamente intuitiva, en función del
conocimiento de las personas.
Para que este tipo de escalas puedan cumplir con el requisito de garantizar resultados
comparables y reproducibles a lo largo del tiempo de manera que, un nivel de riesgo no
suba o baje sin que exista una razón clara asociada, se deben adaptar o ajustar según unas
referencias a circunstancias y descripciones orientativas que permitan acotar las distintas
magnitudes.
199
La estimación de tipo cualitativo se puede utilizar en alguna o varias de las siguientes

situaciones:
• Como actividad de evaluación inicial para determinar los riesgos que requerirán
posteriormente un análisis más detallado.
• Cuando este tipo de análisis se encuentra como el más apropiado para la toma de
decisiones.
• Cuando la cantidad de datos numéricos o los recursos no son adecuados para

afrontar una estimación del tipo cuantitativo.
El análisis cualitativo debe utilizar, siempre que sea posible, la información relevante ba-
sada en hechos y datos objetivos de referencia.
22.2.1.2. Metodologías cuantitativas

La estimación cuantitativa hace uso de una escala de valores numéricos, tanto para las
consecuencias como para la probabilidad, utilizando datos documentados procedentes de
una variedad habitualmente amplia de fuentes de información relevantes.
La calidad de los análisis depende de la exactitud e integridad de los valores numéricos y

la validez de los modelos utilizados.
La estimación cuantitativa se basa, principalmente, en datos históricos de incidentes, pro-

porcionando la ventaja de que puede estar directamente relacionada con los objetivos de
seguridad de la información y las cuestiones relevantes que preocupan a la organización.
Una desventaja es la frecuente falta de datos, especialmente cuando aparecen nuevos

riesgos o debilidades en la seguridad de la información. Precisamente, esta falta de datos
reales y verificables puede llevar al desarrollo de valoraciones basadas en proyecciones
o modelos teóricos de valoración pero que se dan como reales y fiables por el hecho de
participar dentro de una estimación de tipo cuantitativo.
La forma en que se representan las consecuencias y la probabilidad y las formas en que se

combinan para proporcionar un nivel de riesgo suele variar en función del tipo de riesgo
y el propósito para el que se va a utilizar posteriormente, una vez generado el informe de
evaluación de riesgos.
200
Este tipo de estimaciones conllevan la necesidad de:
• Dedicar un tiempo significativo en las actividades de valoración.
• Recursos especializados especialmente costosos en el caso de algunos sectores

industriales.
• Ayudas externas de consultorías especializadas y/o contactos con organismos re-

levantes que aporten datos relevantes.
Otro aspecto importante a considerar tiene relación con la información obtenida y que,
empieza a ser realmente representativa a medio y largo plazo, una vez la metodología está
en marcha y se ha aplicado durante un tiempo necesario para que las bases de valoración
consoliden una base histórica lo suficientemente fiable como para poder tomar decisio-
nes.
22.2.1.3. Metodologías mixtas

El desarrollo de estimaciones denominadas “semi-cualitativas” o “semi-cuantitativas” tie-
ne como objetivo principal aprovechar los aspectos positivos de cada uno de los enfoques
reduciendo sus distorsiones (por ejemplo, subjetividad) o costes (por ejemplo, tiempo o
recursos) implícitos.
Por este motivo, este tipo de estimaciones cuentan con una gran aceptación en las im-
plantaciones de los SGSI por parte de las empresas, sin que esto signifique que siempre
sean la mejor opción.
De hecho, es conocida la experiencia negativa de algunas organizaciones que aplican ini-

cialmente este tipo de metodología desestimando, directamente, las estimaciones cuali-
tativas por una sensación de “falta de objetividad” pero que a corto y medio plazo caen en
la cuenta que no pueden dedicar recursos internos ni externos suficientes para mantener
el esfuerzo asociado a la revisión de las estimaciones fracasando estrepitosamente en las
labores de su mantenimiento.
En el caso de las personas que desarrollan trabajos de consultoría especializada en la im-

plantación de metodologías, necesitan conocer en detalle diversos tipos de aplicación de
estimaciones y soluciones asociadas para que puedan recomendar aquellas más adecua-
das según el proyecto de implantación y los recursos disponibles para el mantenimiento
posterior del SGSI.
201
22.2.2. Valoración de los riesgos

A continuación, se exponen de forma conceptual en qué consisten las valoraciones de los
riesgos y su gestión posterior en base a las conclusiones que se derivan.
Hay dos grandes tareas a realizar dentro de la valoración de riesgos:
• Análisis de riesgos: utilización sistemática de la información disponible para

identificar peligros y estimar los riesgos.
Elementos:
• Activos: elementos del sistema de información (o estrechamente relacionados

con éste) que aportan valor a la organización.
• Amenazas: causas potenciales de incidentes no deseados, que pueden causar

daño a un sistema o la organización.
• Vulnerabilidades: debilidades en la seguridad de la información de una organi-

zación que, potencialmente, permiten que una amenaza afecte a un activo.
• C
ontroles, salvaguardas o contramedidas: las políticas, los procedimientos, las
prácticas y las estructuras organizativas concebidas para mantener los riesgos
de seguridad de la información por debajo del nivel de riesgo asumido.
Con estos elementos se puede estimar:
• El impacto: en términos de coste para la empresa de un incidente de la escala

que sea y que puede o no ser medido en términos estrictamente financieros (por
ejemplo, pérdida de reputación, implicaciones legales, entre otros).
• E
l riesgo: en términos de estimación del grado de exposición a que una amenaza
se materialice sobre uno o más activos causando daños o perjuicios a la organi-
zación.
El análisis de riesgos permite analizar estos elementos de forma metódica para

llegar a resultados fundamentados en la realidad de la empresa y de manera
reproducible.
• Evaluación de riesgos: proceso de comparar el riesgo estimado previamente con-

tra un criterio de riesgo dado con el objeto de determinar la importancia del riesgo.
El criterio de riesgo utilizado para determinar si es obligado o no desarrollar accio-

nes de gestión del riesgo se denomina riesgo aceptable.
202
Todas estas actividades forman parte del proceso global de gestión del riesgo con objeto
de poder dirigir y controlar una organización con respecto a los riesgos.
De este modo, se habilita el modo de organizar la defensa concienzuda y prudente de

manera que se procure evitar daños potenciales, al mismo tiempo que la organización se
prepara del mejor modo para atajar las emergencias, sobrevivir a los incidentes y seguir
operando en las mejores condiciones.
La gestión de la seguridad de un sistema de información implica la gestión de sus riesgos

y el análisis de los mismos permite racionalizar dicha gestión y el esfuerzo que la organi-
zación debe dedicar.
22.2.2.1. Análisis de riesgos

El análisis de riesgos es una aproximación metódica para determinar el riesgo siguiendo
unos pasos pautados dentro del alcance definido previamente:
• Determinar los activos relevantes ( junto a los propietarios asignados) a la organi-

zación, su interrelación y su valor, en el sentido de qué perjuicio (coste) supondría
su degradación.
• Determinar a qué amenazas están expuestos aquellos activos.
• Determinar las vulnerabilidades que podrían ser aprovechadas por las amenazas
para identificar los impactos que las pérdidas de confidencialidad, integridad y
disponibilidad puedan tener sobre los activos.
Dentro del último paso y relacionado con la identificación de impactos existe una práctica
habitual que consiste en desarrollar estimaciones de impacto y riesgo sobre escenarios
“potenciales” y para los que se considera que no hay ninguna salvaguarda establecida por
parte de la organización, aún cuando realmente ya existan medidas de control para los
activos.
De este modo, aunque el estándar ISO/IEC 27001 no lo tenga establecido como requisito,
se puede analizar el denominado riesgo inherente a cada activo (sin controles) además
del nivel de riesgo actual (considerando los controles actuales acometidos por la organi-
zación).
Este análisis extra puede permitir visualizar mejor en qué grado protegen los controles
establecidos los activos y localizar puntos de mejora en su eficiencia, además de orientar
a la organización acerca del posible esfuerzo asociado en el caso de introducir medidas
adicionales para una reducción del nivel del riesgo en activo concreto.
203
Independientemente del escenario teórico planteado mediante un cálculo del riesgo in-
herente, sí se deben desarrollar en cualquier caso identificaciones realistas del impacto
y riesgos asociados a los elementos y en base a los controles actualmente implantados.
22.2.2.1.1. Activos
Se denominan activos los recursos del sistema de información o relacionados con éste,
necesarios para que la organización funcione correctamente y alcance los objetivos pro-
puestos por su dirección.
El activo esencial es la información que maneja el sistema.
En el contexto aquí tratado, se entiende por información todo aquel conjunto de datos or-
ganizados en poder de una entidad que poseen valor para la misma, independientemente
de la forma en que se guarde o transmita (escrita, en imágenes, oral, impresa en papel,
almacenada electrónicamente, proyectada, enviada por correo, fax o e-mail, transmitida
en conversaciones, etc.), de su origen (de la propia organización o de fuentes externas) o
de la fecha de elaboración.
Alrededor de esta información, se pueden identificar otros activos relevantes que no nece-
sariamente contienen datos pero que desarrollan una labor fundamental asociada como
son:
• Los servicios que se pueden prestar gracias a aquellos datos, y los servicios que se
necesitan para poder gestionar dichos datos.
• Las aplicaciones informáticas (software) que permiten manejar los datos.
• Los equipos informáticos (hardware) y que permiten hospedar datos, aplicaciones

y servicios.
• Los soportes de información que son dispositivos de almacenamiento de datos.
• El equipamiento auxiliar que complementa el material informático.
• Las redes de comunicaciones que permiten intercambiar datos.
• Las instalaciones que acogen equipos informáticos y de comunicaciones.
• Las personas que explotan u operan todos los elementos anteriormente citados.
204
No todos los activos son de la misma clase. Dependiendo del tipo de activo, las amenazas,
vulnerabilidades y las salvaguardas son diferentes.
Si el sistema maneja datos de carácter personal, estos suelen ser importantes por sí mis-
mos y requerir una serie de salvaguardas frecuentemente reguladas por ley. En estos acti-
vos interesa determinar qué tratamiento hay que imponerles.
El hecho de que un dato sea de carácter personal impacta sobre todos los activos involu-
crados en su tratamiento y custodia.
Algo similar ocurre con los datos sometidos a una clasificación de confidencialidad.
Cuando se dice que un cierto informe está clasificado como “reservado”, de forma que las
copias están numeradas, sólo pueden llegar a ciertas personas, no deben salir del recinto
y deben ser destruidas concienzudamente, etc. se están imponiendo una serie de salva-
guardas porque lo ordena el reglamento, sectorial o específico de la organización.
Los activos más llamativos suelen ser los datos y los servicios, pero estos activos depen-
den de otros activos más prosaicos como pueden ser los equipos, las comunicaciones o
las frecuentemente olvidadas personas que trabajan con aquéllos.
Por ello, aparece como importante el concepto de “dependencias entre activos” o la medi-
da en que un activo superior se vería afectado por un incidente de seguridad en un activo
inferior.
Se dice que un “activo superior” depende de otro “activo inferior” cuando las necesidades
de seguridad del superior se reflejan en las necesidades de seguridad del inferior.
Dicho en otras palabras, cuando la materialización de una amenaza en el activo inferior

tiene como consecuencia un perjuicio sobre el activo superior. Informalmente, puede in-
terpretarse que los activos inferiores son los pilares en los que se apoya la seguridad de
los activos superiores.
Aunque en cada caso hay que adaptarse a la organización objeto del análisis, con fre-
cuencia se puede estructurar el conjunto de activos en capas, donde las capas superiores
dependen de las inferiores a modo de muñecas rusas:
• Capa 1 (el entorno): activos que se precisan para garantizar el equipamiento y su-
ministros (energía, climatización, comunicaciones), personal (de dirección, de ope-
ración, de desarrollo, etc.), instalaciones (edificios, mobiliario, etc.).
205
• Capa 2 (el sistema de información propiamente dicho):Equipos informáticos (hard-

ware).
• Aplicaciones (software).
• Comunicaciones.
• Soportes de información: discos, cintas, etc.
• Capa 3: (la información):
• Datos.
• Meta-datos: estructuras, índices, claves de cifra, etc.
• Capa 4: las funciones de la organización, que justifican la existencia del sistema de

información y le dan finalidad:
• Objetivos y misión.
• Bienes y servicios producidos.
• Capa 5: otros activos:
• Credibilidad o buena imagen.
• Conocimiento acumulado.
• Independencia de criterio o actuación.
• Intimidad de las personas.
• Integridad física de las personas.
Si no se puede prescindir impunemente de un activo, es que algo vale; precisamente, eso

es lo que hay que averiguar mediante el análisis pues, en ese mismo grado de valor inte-
resará aplicar medidas y esfuerzos para su protección.
El valor puede ser intrínseco y propio o puede ser acumulado. Se dice que los activos in-
feriores en un esquema de dependencias, acumulan el valor de los activos que se apoyan
en ellos.
El valor nuclear suele estar en la información (o datos) que el sistema maneja, quedando
los demás activos subordinados a las necesidades de explotación y protección de la in-
formación.
206
Por otra parte, los sistemas de información explotan los datos para proporcionar servi-
cios, internos a la organización o destinados a terceros, apareciendo una serie de datos
necesarios para prestar un servicio.
En un árbol de dependencias, donde los activos superiores dependen de los inferiores,

es imprescindible valorar los activos superiores, los que son importantes por sí mismos.
Automáticamente, este valor se acumula en los inferiores, lo que no es óbice para que
también puedan merecer, adicionalmente, su valoración propia.
El conjunto de datos y servicios finales permite caracterizar funcionalmente una organi-

zación. Las dependencias entre activos permiten relacionar los demás activos con datos
y servicios.
Además de las dependencias entre activos, hay que considerar que de un activo hay que
calibrar diferentes dimensiones:
• Su confidencialidad: ¿qué daño causaría que lo conociera quien no debe?
• Su integridad: ¿qué perjuicio causaría que estuviera dañado o corrupto?
• Su disponibilidad: ¿qué perjuicio causaría no tenerlo o no poder utilizarlo?
Adicionalmente a estas dimensiones, existen entornos que necesitan dimensiones adicio-

nales relacionadas con la autenticidad, trazabilidad o el no repudio, entre otras relevantes.
Por ejemplo, en sistemas dedicados a la administración electrónica o al comercio elec-

trónico, el conocimiento de los actores es fundamental para poder prestar el servicio co-
rrectamente y poder perseguir los fallos (accidentales o deliberados) que pudieran darse.
En estos activos interesa calibrar la:
• La trazabilidad del uso del servicio: ¿qué daño causaría no saber a quién se le pres-
ta tal servicio? O sea, ¿quién hace qué y cuándo?
• La trazabilidad del acceso a los datos: ¿qué daño causaría no saber quién accede a
qué datos y qué hace con ellos?
• Su autenticidad: ¿qué perjuicio causaría no saber exactamente quien hace o ha

hecho cada cosa?
Los aspectos de autenticidad y trazabilidad de los datos son críticos para satisfacer medi-
das reglamentarias sobre ficheros que contengan datos de carácter personal.
207
En cualquier caso, el estándar ISO/IEC 27001 parte únicamente de las tres dimensiones
esenciales para que sea decisión de la organización que implanta y mantiene el SGSI la
que, en base a sus necesidades particulares, extienda el número y tipología de las mismas.
Una vez determinadas qué dimensiones (de seguridad) interesan de un activo hay que
proceder a valorarlo. Se pueden considerar diversos factores relacionados:
• Coste de reposición: adquisición e instalación.
• Coste de mano de obra (especializada) invertida en recuperar (el valor) del activo.
• Lucro cesante: pérdida de ingresos.
• Capacidad de operar: confianza de los usuarios y proveedores que se traduce en

una pérdida de actividad o en peores condiciones económicas sanciones por in-
cumplimiento de la ley u obligaciones contractuales.
• Daño a otros activos, propios o ajenos.
• Daño a personas.
• Daños medioambientales.
La valoración puede ser cuantitativa (con una cantidad numérica) o cualitativa (en alguna
escala de niveles).
Los criterios más importantes a respetar son:
• La homogeneidad: es importante poder comparar valores, aunque sean de diferen-

tes dimensiones a fin de poder combinar valores propios y valores acumulados, así
como poder determinar si es más grave el daño en una dimensión o en otra
• La relatividad: es importante poder relativizar el valor de un activo en comparación

con otros activos.
Todos estos criterios se satisfacen habitualmente con valoraciones económicas (coste di-
nerario requerido para “curar” el activo) ya que la opción de ponerle precio a todo es parte
de la dinámica de gestión empresarial a nivel directivo y, por tanto, se integra mejor en
el lenguaje y contexto general de las actividades y asignación presupuestarias dentro las
organizaciones, especialmente las privadas.
208
En este aspecto, es relativamente sencillo poner precio a los aspectos más tangibles (equi-
pamiento, horas de trabajo, etc.), aunque la dificultad estriba en aquellas valoraciones más
abstractas o relacionadas con activos intangibles, como puede ser la imagen, la credibili-
dad o la reputación de la organización.
En estos casos, aportar una valoración económica exacta es una actividad compleja y que
ocasiona largas discusiones entre los participantes en las valoraciones.
En cualquier caso, habrá que resolver este tipo de diferencias mediante la documentación
de las pautas que finalmente se determinen para garantizar la valoración sistemática de
los activos en subsiguientes análisis.
Por el contrario, las escalas cualitativas permiten avanzar con rapidez, posicionando el
valor de cada activo en un orden relativo respecto de los demás.
Es frecuente plantear estas escalas como “órdenes de magnitud” y, en consecuencia, deri-

var estimaciones del orden de magnitud del riesgo, pero la limitación de las valoraciones
cualitativas es que no permiten comparar valores más allá de su orden relativo (no se
pueden sumar valores).
A favor de las valoraciones cuantitativas se puede indicar que sumar valores numéricos
es absolutamente “natural” y la interpretación de las sumas da lugar a pocos motivos de
controversia.
Si la valoración es dineraria, además se pueden hacer estudios económicos comparando

lo que se arriesga con lo que cuesta la solución respondiendo a preguntas del tipo:
• ¿Vale la pena invertir tanto dinero en esta salvaguarda?
• ¿Qué conjunto de salvaguardas optimizan la inversión?
• ¿En qué plazo de tiempo se recupera la inversión?
• ¿Cuánto es razonable que cueste la prima de un seguro?
Casi todas las dimensiones mencionadas anteriormente permiten una valoración simple
(cualitativa o cuantitativa) excepto en el caso de la disponibilidad.
No es lo mismo interrumpir un servicio una hora o un día o un mes. Puede que una hora
de detención sea irrelevante, mientras que un día sin servicio causa un daño moderado
pero un mes detenido supone habitualmente la parada de la actividad.
209
Al no existir tampoco una proporcionalidad entre el tiempo de interrupción y las conse-

cuencias asociadas, para valorar la indisponibilidad de un activo hay que usar algún tipo
de solución particular que pueda documentar el coste de la interrupción de la disponibili-
dad desde el momento en que aparece hasta que se alcanza una franja de tiempo suficien-
temente representativa y que puede ser de minutos, horas, meses o años.
Este análisis puede ser más o menos laborioso, pero se obtiene la recompensa de extraer
información fundamental no sólo útil para el análisis del riesgo, sino también para el aná-
lisis de impactos que sirve como base para el desarrollo de los planes de continuidad del
negocio y que serán relevantes dentro de la implantación del SGSI para la supervivencia
de las actividades de la organización en los casos más extremos.
22.2.2.1.2. Amenazas
El siguiente paso consiste en determinar las amenazas que pueden afectar a cada activo.
Las amenazas son “causas potenciales de un incidente no deseado” que están siempre
presentes y fuera de nuestras posibilidades de control.
Hay accidentes naturales como terremotos o inundaciones, desastres industriales que

causan contaminación o fallos eléctricos y ante los cuales el sistema de información está
expuesto. También existen amenazas causadas por las personas de una manera intencio-
nada o accidental, por errores o malas prácticas.
No todas las amenazas afectan a todos los activos, por tanto, se debe discriminar las rela-
ciones entre el tipo de activo y la causa asociada para acometer aquellas situaciones que
tienen verdadero sentido a las actividades y el entorno de negocio.
Cuando una amenaza se materializa en activo aprovechando una vulnerabilidad, el activo

no se ve afectado habitualmente en todas sus dimensiones C-I-D y/o en la misma cuantía.
Por tanto, una vez determinada cada amenaza relevante a un activo, hay que estimar cuán
vulnerable es el activo considerando aspectos como:
• La degradación: cuán perjudicado resultaría el activo.
• La frecuencia: cada cuánto se materializa la amenaza.
La degradación mide el impacto causado por un incidente en el supuesto de que ocurriera

y se suele caracterizar como una fracción del valor del activo y así aparecen expresiones
como que un activo se ha visto “totalmente degradado”, o “degradado en una pequeña
fracción”.
210
La frecuencia pone en perspectiva la degradación, pues una amenaza puede ser de terri-
bles consecuencias, pero de muy improbable materialización (por ejemplo, catástrofes
naturales) mientras que, otra amenaza puede ser de muy bajas consecuencias, pero tan
frecuente como para acabar acumulando un daño considerable (por ejemplo, un corte en
las comunicaciones cada pocos minutos).
La frecuencia toma como referencia habitual la anualidad con referencias, a modo de

ejemplo:
• Muy frecuente: al menos 1 vez al día.
• Frecuente: al menos 1 vez a la semana.
• Normal: al menos 1 vez al mes.
• Poco frecuente: al menos 1 vez al año.
• Improbable: cada varios años.
Un último aspecto relevante tiene que ver con una adecuada interpretación de las ame-
nazas como “causa potencial” respecto a las vulnerabilidades “debilidad”. Es habitual en-
contrar defectos de interpretación además de carencias importantes en la determinación
y relación de ambos conceptos.
En este sentido, la relación entre amenazas y vulnerabilidades el estándar ISO/IEC

27005:2008 proporciona una ayuda útil con tablas ya definidas similares a las del siguien-
te ejemplo:
Organización
Ejemplos de vulnerabilidades Ejemplos de amenazas
La falta de procedimiento formal de re- El abuso de los

gistro y la cancelación de usuarios derechos
La falta de un proceso formal de revisión de El abuso de los

los derechos de acceso (supervisión) derechos
La falta o insuficiencia de disposicio- El abuso de los

nes (en materia de seguridad) en los con- derechos
tratos con los clientes y / o de terceros
La falta de procedimientos de supervisión de las El abuso de los

instalaciones de procesamiento de la información derechos
211
Organización
La falta de auditorías periódicas de control (supervisión) El abuso de los

derechos
La falta de procedimientos de identi- El abuso de los

ficación y valoración del riesgo derechos
La falta de informes de fallos registrados en los El abuso de los

registros de administrador y de operador derechos
Servicio de mantenimiento inadecuado El incumplimiento del

mantenimiento del
sistema de información
La falta o insuficiencia de Acuerdos de Nivel de Servicio El incumplimiento de

mantenimiento del
La falta de procedimiento de control de los cambios El incumplimiento de

mantenimiento del
La falta de procedimiento formal de con- La corrupción

trol de la documentación del SGSI de los datos
La falta de procedimiento formal para la su- La corrupción

pervisión de registro de SGSI de los datos
La falta de un proceso formal de autori- Datos procedentes de

zación de la información pública fuentes poco fiables
La falta de una adecuada asignación de respon- Denegación de

sabilidades de seguridad de la información las acciones
La falta de planes de continuidad Falla del equipo
La falta de política de uso de e-mail Error en el uso
La falta de procedimientos para la introduc- Error en el uso

ción de software en sistemas operativos
212
Organización
La falta de registros de actividad para Error en el uso

el administrador y operadores
La falta de procedimientos para manejo de información Error en el uso

clasificada
La falta de responsabilidades de seguridad de la infor- Error en el uso

mación en las descripciones de los puestos
La falta o insuficiencia de disposiciones (en materia de Procesamiento ilegal de

seguridad de la información) en los contratos con los datos
empleados
La falta de proceso disciplinario en caso de robo de infor- El robo de equipos

mación y/o incidentes de seguridad de los equipos
La falta de una política formal sobre el uso de equipo El robo de equipos

móvil
La falta de control de los activos fuera del establecimien- El robo de equipos

to
La falta o insuficiencia de políticas de ‘escritorio limpio y El robo de los medios o

pantalla en negro’ documentos
La falta de autorización de instalaciones de procesa- El robo de los medios o

miento de la información documentos
La falta de mecanismos de control establecidas para las El robo de los medios o

infracciones de seguridad documentos
La falta de gestión de revisiones periódicas La utilización no autori-

zada del equipo
La falta de procedimientos para informar de las deficien- La utilización no autori-

cias de seguridad zada del equipo
La falta de procedimientos de cumplimiento de las dispo- El uso de software falsi-

siciones de los derechos intelectuales ficado o copiado
213
22.2.2.1.3. Impacto y niveles de riesgo

Se denomina impacto a la medida del daño sobre el activo derivado de la materialización
de una amenaza.
Conociendo el valor de los activos (en varias dimensiones) y el nivel de exposición en

base a las amenazas y las vulnerabilidades sólo queda valorar el impacto sobre el sistema
para estimar los niveles de riesgo en función de los controles implantados y la probabili-
dad real de las fallas de seguridad.
La única consideración que queda hacer es relativa a las dependencias entre activos. El
impacto acumulado es el calculado sobre un activo teniendo en cuenta su valor acumula-
do (el propio mas el acumulado de los activos que dependen de él) y las amenazas a los
que está expuesto.
El impacto acumulado se puede calcular para cada activo, por cada amenaza y en cada
dimensión de valoración, siendo una función del valor acumulado y de la degradación
causada.
El impacto es tanto mayor cuanto mayor es el valor propio o acumulado sobre un activo y
cuanto mayor sea la degradación del activo atacado.
Por tanto, el impacto acumulado al calcularse sobre los activos que soportan el peso del
sistema de información permite determinar las posibles salvaguardas de que hay que
dotar a los medios de trabajo en su conjunto como la protección de los equipos, copias de
respaldo, etc.
Dato importante
Durante la etapa de evaluación de riesgos, los requisitos contractuales, legales y

reglamentarios son factores que se deben tener en cuenta, además de los riesgos
estimados. El resultado de la evaluación de riesgos es una lista de los riesgos priori-
zados en relación a los escenarios de incidentes que guían esos riesgos.
214
22.2.2.2. Evaluación de riesgos

Es el momento de determinar si los riesgos son aceptables o si requieren tratamiento
utilizando los criterios para la aceptación de los riesgos establecidos. Para ello, se dispone
de una lista de riesgos con los niveles de valor asignado y los criterios de análisis de los
riesgos.
El nivel de riesgo debe ser comparado con los criterios de evaluación de riesgos y criterios
de aceptación del riesgo (en relación con a la norma ISO/IEC 27001, cláusula 4.2.1 e) 4)).
La naturaleza de las decisiones relativas a los criterios de valoración de riesgos y evalua-

ción de los riesgos que se utiliza para tomar esas decisiones y se habría decidido previa-
mente con la determinación de la metodología específica.
Estas decisiones y el contexto de aplicación de la metodología de análisis de riesgos de-

ben ser revisados con más detalle en esta etapa ya que es ahora cuando se conoce más
acerca de los riesgos específicos identificados.
Al evaluar los riesgos, las organizaciones deben comparar los riesgos estimados (median-
te los métodos seleccionados o enfoques comentados) con los criterios de evaluación de
riesgo definidos en el establecimiento de contexto y en función de la propia sistemática y
las dificultades y resultados obtenidos decidir si son susceptibles de revisarse para alcan-
zar el procedimiento de evaluación más adecuado.
Los criterios de evaluación de riesgos utilizados para tomar decisiones deben ser con-
sistentes con los objetivos de la organización y las aportaciones de los participantes, de
modo que, entre otras consideraciones se debería observar en esta actividad:
• Las propiedades de seguridad de la información: si un criterio no es relevante para

la organización (por ejemplo, la pérdida de confidencialidad), entonces todos los
riesgos que afectan a este criterio puede ser no relevantes.
• La importancia de los procesos de negocio o actividad con el apoyo de un activo

o un conjunto de activos: si el proceso se determina que es de poca importancia, a
riesgos asociados a ella se debe dar una baja consideración.
215
Las decisiones adoptadas en la actividad de evaluación de riesgo se centran principal-

mente en la aceptación del nivel de riesgo para cada activo analizado. Sin embargo, se
debe considerar que las consecuencias, la probabilidad y el grado de confianza en la iden-
tificación de los riesgos desarrollado mediante el propio proceso de análisis puede resul-
tar en una posible agregación de múltiples riesgos bajos o medios que deben abordarse,
aunque individualmente puedan quedar relegados a un segundo plano por aquellos nive-
les de riesgo más altos.
La evaluación de riesgos utiliza el conocimiento en los riesgos obtenido por el análisis de

riesgos para tomar decisiones relevantes sobre las futuras acciones. Las decisiones deben
considerar:
• Las actividades que se llevarán o no a cabo.
• Las prioridades para el tratamiento del riesgo teniendo en cuenta los niveles de
riesgo estimados.
Durante la etapa de evaluación de riesgos, los requisitos contractuales, legales y regla-

mentarios son factores que se deben tener en cuenta, además de los riesgos estimados.
El resultado de la evaluación de riesgos es una lista de los riesgos priorizados en relación

a los escenarios de incidentes que guían esos riesgos.
22.2.3. Tratamiento del riesgo

Según los criterios de aceptación de riesgo previamente establecidos, se debe determinar
por la dirección de la organización si el riesgo es aceptable o necesita ser tratado.
Las distintas opciones de tratamiento de los riesgos deben ser identificadas y valoradas
en relación las siguientes estrategias posibles:
• Reducir el riesgo aplicando controles adecuados.
• Aceptar el riesgo, siempre y cuando se siga cumpliendo con las políticas y criterios
establecidos para la aceptación de los riesgos.
• Evitar el riesgo, por ejemplo, mediante el cese de las actividades que lo originan.
• Transferir el riesgo a terceros, por ejemplo, compañías aseguradoras o proveedores

de outsourcing, entre otras posibles.
Las cuatro opciones para el tratamiento de los riesgos no son excluyentes mutuamente.
De hecho, la organización se puede beneficiar sustancialmente por una combinación de
opciones tales como la reducción de la probabilidad de los riesgos, reducir sus consecuen-
cias y la transferencia o retención de cualquier riesgo residual.
216
Algunos tratamientos para el riesgo pueden servir para abordar más de un riesgo (por
ejemplo, acciones de capacitación y concienciación en seguridad).
En el caso de reducir el riesgo aplicando controles, hay que planificar el conjunto de sal-
vaguardas pertinentes para atajar tanto el impacto (por ejemplo, reduciendo su impor-
tancia introduciendo elementos redundantes) como el riesgo reduciendo el impacto en
la organización y/o la frecuencia asociada minimizando sus oportunidades (por ejemplo,
reduciendo las vulnerabilidades con un mantenimiento o monitorización más frecuente).
Todo nivel de riesgo puede ser abordado mediante acciones como:
• Establecer una política al respecto mediante directrices comunes.
• Establecer unos objetivos a satisfacer para saber los niveles de referencia a alcan-
zar y mantener.
• Establecer unos procedimientos claros con instrucciones paso a paso de qué hay
que hacer, quién y cómo se deben realizar.
• Desplegar salvaguardas adecuadas y mediciones para verificar su efectividad se-

gún lo previsto.
En este último punto y para la selección de salvaguardas adecuadas, ISO/IEC 27001 en

su anexo A incluye un listado de 11 áreas de actuación con 39 objetivos de control y 133
controles que permiten disponer de un catálogo de referencia para la elección de solucio-
nes adecuadas.
Precisamente y de manera más extensa, se comentan estos objetivos de control y contro-

les más adelante, de forma específica, en el tema 5.
En cualquier caso, el anexo A indica el objetivo del control a cumplir, pero no cómo desa-
rrollarlo así que el documento de referencia de utilidad en las actividades de implantación
es ISO/IEC 27002, que tiene una referencia directa en la numeración de las cláusulas de
los controles con el anexo A de ISO/IEC 27001 y que comienza con el A5 y acaba en el
A15 por este motivo.
En el caso que la organización no encuentre suficientes propuestas en el marco ISO/IEC

27001 e ISO/IEC 27002, existe la posibilidad de acudir a cualquier otro marco de referen-
cia o al propio sentido común para acometer acciones adaptadas a sus necesidades de
actuación sobre los riesgos.
Para llevar un registro adecuado y diferenciación de las actividades relacionadas con ob-
jetivos de control ya desarrolladas por la organización respecto a las nuevas actividades
que se vayan a acometer mediante el plan de tratamiento del riesgo, existe un documento
denominado “declaración de aplicabilidad” como registro de actuación.
217
De igual modo y con el objeto de evitar que inadvertidamente se hayan obviado algunos
aspectos relevantes, se debe justificar el motivo que lleva a no desarrollar actividades de
ningún tipo (ni actualmente ni dentro del plan de tratamiento) en aquellos controles que
se desestimen.
Un sistema debe considerar, prioritariamente, las salvaguardas de tipo preventivo que

eviten que la amenaza no se materialice produciendo daños. Es decir, impedir incidentes
o ataques.
En la práctica, no todo es previsible, ni todo lo previsible es económicamente razonable

atajarlo en sus orígenes. Tanto para enfrentar lo desconocido como para protegerse de
aquello a lo que se permanece expuesto, es necesario disponer de elementos que detecten
el inicio de un incidente y permitan reaccionar en el tiempo requerido, antes de que se
convierta en un impacto considerable o, incluso en un desastre.
Es de sentido común intentar actuar de forma preventiva para evitar la ocurrencia o para
no causar un impacto significativo, pero no siempre es posible y hay que estar preparados
para actuar cuando ocurran.
Lo que no es admisible es que un ataque pase inadvertido, por tanto, la organización tiene
que adoptar controles para la detección, registro y notificación relevantes que habiliten
una respuesta temprana.
En los incidentes más graves, se suelen activar planes de gestión de incidentes que con-
tengan y limiten la actuación y consecuencias del incidente, llegando al punto de activar
el plan de continuidad y recuperación de organización a la actividad normal en los esce-
narios más adversos.
Es de sentido común que no se puede invertir en salvaguardas más allá del valor de los
propios activos a proteger.
Las opciones de tratamiento del riesgo deben ser seleccionadas en base a:
• Los resultados de la evaluación del riesgo.
• El costo esperado para la implementación de las opciones.
• Los beneficios esperados de estas opciones.
En el caso que se puedan obtener grandes reducciones en los niveles de riesgos con un
gasto relativamente bajo, se deben implantar estas opciones.
218
En el caso de otras opciones que no sean tan claras en la relación de rentabilidad, para la
mejora se debe juzgar si existe un margen para justificar una decisión favorable suficien-
temente.
Figura 1. Coste de la desprotección versus coste de las salvaguardasFuente:

elaboración propia.
Fuente: Magerit versión 2 - Ministerio de Administraciones Públicas.
Aparecen en la práctica gráficos como el anterior que enfrentan el coste de la inseguridad

(lo que costaría no estar protegidos) y el coste de las salvaguardas.
Este tipo de gráficas intentan reflejar cómo al avanzar de un grado de seguridad 0 hacia
un grado de seguridad ideal del 100%, el coste de la inseguridad (el riesgo) disminuye,
mientras que el coste de la inversión en salvaguardas aumenta.
Es intencionado el hecho de que el riesgo caiga fuertemente con pequeñas inversiones y

que el coste de las inversiones se dispare para alcanzar niveles de seguridad cercanos al
100%.
La curva central suma el coste para la organización, bien derivado del riesgo (baja segu-
ridad), bien derivado de la inversión en protección. De alguna forma, existe un punto de
equilibrio entre lo que se arriesga y lo que se invierte en defensa, punto al que hay que
tender si la única consideración es económica.
Pero llevar el sentido común a la práctica no es evidente, ni por la parte del cálculo del
riesgo, ni por la parte del cálculo del coste de las salvaguardas. En otras palabras, la curva
anterior es conceptual y es complejo de representar en un caso real.
219
Un análisis económico tendrá como misión decidir entre estas opciones, siendo la opción
de aceptar/contener la situación actual sin aplicar nada una opción posible, que pudiera
estar justificada económicamente.
En escenarios de aplicación de uno o varios controles se puede estimar la ratio del cos-
te/beneficio a lo largo del tiempo mediante la suma de los cálculos parciales relativos a
cuestiones como:
• Coste negativo: el riesgo residual (recurrente).
• Coste negativo: el coste de las salvaguardas (inicial).
• Coste negativo: el coste anual de mantenimiento (recurrente).
• Coste positivo: mejora en la productividad (recurrente).
• Coste positivo: mejoras en la capacidad de la organización para prestar nuevos

servicios, conseguir mejores condiciones de los proveedores, entrar en asociación
con otras organizaciones, etc. (recurrente).
En función de los resultados de las estimaciones podemos obtener distintos resultados

que se representan e interpretan, a continuación, y a modo de ejemplo, de este tipo de
valoraciones:
• En E0 se sabe lo que cada año (se estima que) se pierde.
• El escenario E1 aparece como mala idea, pues supone un gasto añadido el primer
año, pero este gasto no se recupera en años venideros.
• No así el escenario E2 que, suponiendo un mayor desembolso inicial, empieza a ser

rentable a partir del cuarto año.
• Más atractivo aún es el escenario E3 en el que a costa de un mayor desembolso

inicial, se empieza a ahorrar al tercer año, e incluso se llega a obtener beneficios
operativos a partir del quinto año. Se puede decir que en escenario E3 se ha hecho
una buena inversión.
220
Figura 2. Cálculo de coste/beneficio en función de la aplicación de distintas estrategias de aplicación de

controles.
Fuente: Magerit versión 2 - Ministerio de Administraciones Públicas.
En general, las consecuencias negativas de los riesgos deben ser reducidas tanto como
sea razonablemente posible e independientemente de cualquier criterio absoluto o siste-
ma de valoración como el anteriormente descrito.
Otro punto de difícil consideración por parte de los gerentes son aquellos riesgos poco
frecuentes pero graves cuando se producen. En tales casos, los controles que no pueden
ser justificados por motivos estrictamente económicos pueden ser implantados en con-
sideración a riesgos de alto grado como, por ejemplo, controles asociados a los planes de
continuidad de negocio de la organización.
Un plan de tratamiento del riesgo se debe definir de modo que identifique claramente las
prioridades de orden en el que los tratamientos individuales del riesgo deben ser imple-
mentadas junto a sus plazos (cláusula 4.2.2 a) de ISO/IEC 27001). Las prioridades se pue-
den establecer con varias técnicas, incluido el ranking de los niveles de riesgos y el análi-
sis de costo-beneficio. En todo caso, es responsabilidad de la dirección de la organización
decidir el equilibrio entre el coste asociado a los controles que se pretenden implantar y
la asignación del presupuesto necesario.
221
La identificación de los controles existentes podría determinar que los controles ya exis-
tentes son excesivos para las necesidades actuales, en términos de comparación de su
coste e incluyendo el mantenimiento.
Si la eliminación de controles redundantes o innecesarios se determina como opción de

eficiencia se debe considerar el factor de influencia de esta eliminación en los demás
controles ya que, la eliminación de controles redundantes podría reducir el nivel de segu-
ridad en algún aspecto.
Además, debe considerarse la situación en que sea más económico mantener controles
redundantes o innecesarios que retirarlos.
Como resultado final de esta labor, se obtiene el plan de tratamiento del riesgo y los ries-
gos residuales sujetos a la decisión de aceptación del órgano directivo de la organización.
22.2.3.1. Aceptación del riesgo

La dirección de la organización sometida al análisis de riesgos debe determinar el nivel
de impacto y riesgo aceptable. Más propiamente dicho, debe aceptar la responsabilidad
de aceptar un nivel de riesgo con cierto grado de insuficiencias.
Esta decisión no es técnica. Puede ser una decisión política o gerencial o puede venir de-
terminada por ley o por compromisos contractuales con proveedores o usuarios.
Estos niveles de aceptación se pueden establecer por activo o por agregación de activos
(en un determinado departamento, en un determinado servicio, en una determinada di-
mensión, etc.)
Una vez que el plan de tratamiento del riesgo ha sido implantado a fin de alcanzar los
objetivos de control identificados con la inclusión de la consideración del financiamiento
y la asignación de los roles y las responsabilidades, sólo queda determinar los riesgos
residuales.
Algunas salvaguardas, especialmente las de tipo técnico, se traducen en el despliegue

de más equipamiento que se convierte, a su vez, en un activo del sistema. Estos activos
soportan parte del valor del sistema y están a su vez sujetos a amenazas que pueden per-
judicar a los activos de valor.
Hay pues que repetir el análisis de riesgos, ampliándolo con el nuevo despliegue de me-
dios y, por supuesto, cerciorarse de que el riesgo del sistema ampliado es menor que el
del sistema original; es decir, que las salvaguardas efectivamente disminuyen el estado
de riesgo de la organización.
222
El cálculo de los riesgos residuales implica una actualización o reiteración de la evalua-

ción del riesgo, teniendo en cuenta los efectos esperados del tratamiento de riesgos pro-
puestos con los nuevos controles ya en funcionamiento e información relevante el grado
de eficacia obtenido.
Puede darse el caso de que el riesgo residual todavía no cumpla con los criterios de la
organización en relación a los niveles de aceptación del riesgo. En ese caso, una nueva
iteración para introducir nuevos planes del tratamiento de riesgo podría ser necesaria y
tantas veces como sea necesario antes de proceder a la aceptación del riesgo residual.
Cualquier nivel de impacto y/o riesgo es aceptable si lo conoce y acepta formalmente

la dirección y siempre que vaya sustentado por las consideraciones relevantes al coste/
beneficio que sean oportunas (cláusula 0.3 de ISO/IC 27001).
22.2.4. Comunicación del riesgo

Toda la información del riesgo obtenida de las actividades anteriores para la gestión de
riesgos debe ser intercambiada y compartida entre aquellos que toman las decisiones y
otras partes interesadas en las actividades de la organización.
La comunicación de los riesgos es una actividad necesaria para alcanzar un acuerdo sobre
cómo gestionar los riesgos a través del intercambio de información entre los que toman
decisiones y otros interesados. La información incluye la existencia, naturaleza, forma,
probabilidad, la gravedad, el tratamiento y la aceptabilidad de los riesgos, entre otras
consideraciones adicionales.
Una comunicación efectiva a las partes interesadas es importante ya que puede tener un
impacto significativo en las decisiones que se deben acometer. La comunicación bidirec-
cional asegurará de que ambas partes, responsables de implementar la gestión de riesgos
y los que tienen interés en las actividades de la organización, comprendan la base sobre la
que ciertas decisiones se toman y por qué determinadas acciones son necesarias.
La percepción del riesgo puede variar debido a diferencias en los casos supuestos, los
conceptos y las necesidades, problemas e inquietudes de los interesados en relación al
riesgo o a los temas en discusión.
Los interesados probablemente obtengan sus juicios sobre la aceptabilidad del riesgo en
base a su percepción del riesgo. Esto es especialmente importante para asegurar que sus
percepciones del riesgo, así como la de los beneficios, puedan ser identificadas y docu-
mentadas y las razones claramente comprendidas y tratadas.
223
La comunicación del riesgo debe llevarse a cabo con el fin de:
• Aportar garantías de los resultados de la gestión de riesgos.
• Recoger información sobre los riesgos.
• Compartir los resultados de la evaluación del riesgo y presentar el plan de trata-

miento del riesgo.
• Evitar o reducir tanto la ocurrencia como las consecuencias de las brechas de segu-
ridad de la información por la falta de entendimiento mutuo entre los responsables
políticos y las partes interesadas en la organización.
• Apoyar la toma de decisiones.
• Obtener nuevos conocimientos de seguridad de información.
• Coordinar y planificar las respuestas en la reducción de las consecuencias de cual-

quier incidente.
• Dar un sentido de responsabilidad en lo concerniente a los riesgos a todas las par-

tes y mejorar la concienciación.
Una organización debe desarrollar planes de comunicación de los riesgos dirigidos a las
operaciones normales y a las situaciones de emergencia. Por lo tanto, la comunicación de
riesgos es una actividad que se debe realizar continuamente.
La coordinación entre quienes toman las decisiones principales y los interesados se pue-
de lograr mediante la formación de un comité donde poder debatir acerca de los riesgos,
su priorización y el tratamiento adecuado junto a la correspondiente aceptación.
Así mismo, es importante colaborar con el responsable de las relaciones públicas o con la
unidad de comunicaciones que disponga la organización para coordinar todas las tareas
relacionadas con la comunicación de riesgos.
Esto es crucial en el caso de las acciones de comunicación de crisis, por ejemplo, en res-
puesta a incidentes particulares y en que cada vez se deba actuar más rápido y en consi-
deración a nuevos canales de comunicación como las redes sociales.
224
Como resultado final se debe obtener la comprensión del proceso continuo que la or-
ganización desarrolla en materia de seguridad de la información en base a un proceso
sistemático de gestión de riesgos y de los resultados obtenidos.
22.2.5. Monitorización y revisión del riesgo

Los riesgos no permanecen estáticos en el tiempo y sus factores, como el valor de los
activos, los impactos, amenazas, vulnerabilidades, probabilidad de ocurrencia, entre otros
mencionados, deben ser monitoreados y revisados para identificar cualquier cambio en el
contexto de la organización (preferiblemente, en una etapa lo más temprana posible) con
el objetivo de mantener una visión completa del riesgo.
Las amenazas, vulnerabilidades, probabilidad o las consecuencias pueden cambiar de for-

ma brusca sin ninguna indicación. Por tanto, se hace necesaria una vigilancia constante
para poder detectar estos cambios.
Esta actividad puede ser apoyada por servicios externos y que proporcionen información
actualizada sobre las nuevas amenazas o vulnerabilidades.
Las organizaciones deben monitorizar continuamente:
• Los nuevos activos que hayan sido incluidos en el ámbito de la gestión de riesgos.
• La necesidad de modificación de los valores de los activos, por ejemplo, debido a

cambios en los requerimientos del negocio.
• Las nuevas amenazas que pueden estar activas tanto dentro, como fuera de la orga-
nización y que no han sido evaluadas.
• La posibilidad de que nuevas vulnerabilidades o un aumento de las mismas pue-

dan ser aprovechadas por las amenazas.
• Las vulnerabilidades detectadas para determinar aquéllas expuestas a las nuevas

o reemergentes amenazas.
• Una mayor repercusión o incremento en las consecuencias de las amenazas, vulne-

rabilidades y riesgos que resulte en un nivel de riesgo inaceptable.
• Incidentes de seguridad de la información.
225
Las nuevas amenazas, vulnerabilidades o cambios en la probabilidad o en las consecuen-

cias pueden aumentar aquellos riesgos evaluados anteriormente como bajos.
En la revisión de los riesgos de nivel aceptable se debe considerar cada riesgo por sepa-
rado, por una parte, y todos los riesgos en su conjunto en base a la agregación, por la otra,
para evaluar su potencial impacto acumulado.
Los riesgos considerados como no aceptables deben ser tratados con una o más de las
opciones consideradas en secciones anteriores.
Los factores que afectan la probabilidad y consecuencias de las amenazas que ocurren
podrían cambiar, al igual que los factores que afectan la conveniencia o coste de las dife-
rentes opciones de tratamiento.
Los principales cambios que afectan a la organización deberían ser motivo de una re-
visión más específica. Por lo tanto, las actividades de monitorización del riesgo serán
frecuentes y las opciones seleccionadas para el tratamiento revisadas periódicamente.
El resultado de las actividades de seguimiento de los riesgos puede servir de entrada a

otras actividades de revisión del riesgo. La organización debería revisar regularmente
todos los riesgos, además de cuando se producen cambios importantes (de acuerdo con
la norma ISO/IEC 27001, cláusula 4.2.3)).
Como resultado obtenemos una alineación continua de la gestión de riesgos con los obje-
tivos de negocio de la organización y con los criterios de aceptación de riesgo.
Dato importante
Los riesgos no permanecen estáticos en el tiempo y sus factores, como el valor de

los activos, los impactos, amenazas, vulnerabilidades y probabilidad de ocurrencia,
entre otros, deben ser monitoreados y revisados para identificar cualquier cambio
en el contexto de la organización (preferiblemente, en una etapa lo más temprana
posible) con el objetivo de mantener una visión completa del riesgo.
226
Apartado Contenido
Acometer la seguridad de la información mediante una metodo-

logía de gestión de riesgos acorde a los requisitos indicados por
ISO/IEC 27001, permite a las organizaciones a acometer medidas
de gestión empresarial y organizacional con un enfoque holístico
Introducción e integrado significativamente más eficaz que aquellas organiza-
ciones que realizan esfuerzos en seguridad en base a soluciones
tecnológicas o decisiones acometidas desde ciertos departamen-
tos de forma aislada.
Distinguir entre los distintos tipos de metodologías más habitua-

les.
Comprender la fase de análisis del riesgo mediante las actividades

de identificación y valoración de los riesgos.
Objetivos
Desarrollar la evaluación del riesgo para poder generar un informe
detallado.
Conocer las estrategias disponibles para la gestión de los niveles

de riesgo considerados como no aceptables.
Activo: componente o funcionalidad de un sistema de informa-

ción susceptible de ser atacado deliberada o accidentalmente con
consecuencias para la organización. Incluye: información, datos,
servicios, aplicaciones (software), equipos (hardware), comunica-
ciones, recursos administrativos, recursos físicos y recursos hu-
manos.
Amenaza: causa potencial de un incidente no deseado, el cual

puede causar el daño a un sistema o la organización.
Análisis de riesgos: utilización sistemática de la información dis-

ponible para identificar peligros y estimar los riesgos.
Términos
Comunicar el riesgo: intercambiar o compartir información del
y riesgo entre el responsable del riesgo y otras partes interesadas.
definiciones Control: las políticas, los procedimientos, las prácticas y las es-
tructuras organizativas concebidas para mantener los riesgos de
seguridad de la información por debajo del nivel de riesgo asumi-
do. Control es también utilizado como sinónimo de salvaguarda o
contramedida.
Evaluación de riesgos: comparar el riesgo estimado contra un

criterio de riesgo dado con el objeto de determinar la importancia
del riesgo.
Evitar el riesgo: decisión de no involucrarse en una situación de

riesgo, o posibles acciones que podrían desembocar en situaciones
de riesgo.
227
Apartado Contenido
Gestión de riesgos: actividades coordinadas para dirigir y con-

trolar una organización con respecto a los riesgos.
Identificar riesgos: proceso para localizar, listar y determinar

los atributos de los elementos del riesgo.
Impacto: coste para la empresa de un incidente de la escala que

sea y que puede o no ser medido en términos estrictamente fi-
nancieros.
Medidas de seguridad: conjunto de disposiciones encaminadas

a protegerse de los riesgos posibles sobre el sistema de informa-
ción, con el fin de asegurar sus objetivos de seguridad. Puede
tratarse de medidas de prevención, de disuasión, de protección,
de detección y reacción, o de recuperación.
Plan de tratamiento de riesgos: documento de gestión que

define las acciones para reducir, prevenir, transferir o asumir los
riesgos de seguridad de la información inaceptables e implantar
Términos los controles necesarios para proteger la misma.
y Reducción del riesgo: medidas para reducir la probabilidad y/o

las consecuencias negativas de un riesgo.
definiciones Requisitos mínimos de seguridad: exigencias necesarias para
asegurar la información y los servicios.
Retención del riesgo: aceptación de la carga asociada a la pér-

dida introducida por un riesgo.
Riesgo: estimación del grado de exposición a que una amenaza

se materialice sobre uno o más activos causando daños o perjui-
cios a la organización.
Transferir el riesgo: compartir la carga asociada a la pérdida

introducida por un riesgo.
Trazabilidad: propiedad o característica consistente en que las

actuaciones de una entidad pueden ser imputadas exclusivamente
a dicha entidad.
Valoración del riesgo. Proceso completo de análisis y evaluación

de riesgos.
228
Apartado Contenido
Metodologías cualitativas
Aquellas metodologías que desarrollan estimaciones cualitativas

utilizan una escala de calificación de atributos para describir la
magnitud de las posibles consecuencias (“baja”, “media” y “alta”)
y la probabilidad de que esas consecuencias se produzcan.
Metodologías cuantitativas
La estimación cuantitativa hace uso de una escala de valores nu-

méricos, tanto para las consecuencias como para la probabilidad,
utilizando datos documentados procedentes de una variedad habi-
tualmente amplia de fuentes de información relevantes.
Metodologías mixtas
El desarrollo de estimaciones denominadas “semi-cualitativas” o

“semi-cuantitativas” tiene como objetivo principal aprovechar los
aspectos positivos de cada uno de los enfoques reduciendo sus
Gestión distorsiones (por ejemplo, subjetividad) o costes (por ejemplo,
tiempo o recursos) implícitos.
del
Valoración de riesgos
riesgo
Consiste, principalmente, en las siguientes dos tareas:
Análisis de riesgos: utilización sistemática de la información dis-

ponible para identificar peligros y estimar los riesgos. El análisis de
riesgos permite analizar estos elementos de forma metódica para
llegar a resultados fundamentados en la realidad de la empresa y
de manera reproducible.
Evaluación de riesgos: proceso de comparar el riesgo estimado

previamente contra un criterio de riesgo dado con el objeto de
determinar la importancia del riesgo. El criterio de riesgo utilizado
para determinar si es obligado o no desarrollar acciones de gestión
del riesgo se denomina “riesgo aceptable”.
Tratamiento del riesgo
Según los criterios de aceptación de riesgo previamente estable-

cidos, se debe determinar por la dirección de la organización si el
riesgo es aceptable o necesita ser tratado.
229
Apartado Contenido
Las distintas opciones de tratamiento de riesgos deben ser identi-

ficadas y valoradas en relación a las siguientes estrategias:
Reducir el riesgo aplicando controles adecuados.
Aceptar el riesgo, siempre y cuando se siga cumpliendo con las

políticas y criterios establecidos para la aceptación de los riesgos.
Evitar el riesgo, por ejemplo, mediante el cese de las actividades

que lo originan.
Transferir el riesgo a terceros, por ejemplo, compañías asegurado-

ras o proveedores de outsourcing, entre otras.
Aceptación del riesgo

Gestión
La dirección de la organización sometida al análisis de riesgos
debe determinar el nivel de impacto y riesgo aceptable. Más pro-
del piamente dicho, debe aceptar la responsabilidad de la aceptar un
nivel de riesgo con cierto grado de insuficiencias.
riesgo
Comunicación del riesgo
Toda la información del riesgo obtenida de las actividades ante-

riores para la gestión de riesgos debe ser intercambiada y com-
partida entre aquéllos que toman las decisiones y otras partes
interesadas en las actividades de la organización.
Monitorización y revisión del riesgo
Los riesgos no permanecen estáticos en el tiempo y sus factores,

como el valor de los activos, los impactos, amenazas, vulnera-
bilidades, probabilidad de ocurrencia, entre otros mencionados,
deben ser monitoreados y revisados para identificar cualquier
cambio en el contexto de la organización (preferiblemente, en una
etapa lo más temprana posible) con el objetivo de mantener una
visión completa del riesgo.
230
23. Herramientas de respaldo

“Es la información y su seguridad la que se ha convertido en el fac-
tor esencial para una enorme gama de organizaciones. Hoy en día,
dentro de todo plan de sistemas en de la empresa, se debe contar
con herramientas de respaldo que permitan garantizar la continui-
dad del negocio en caso de algún imprevisto.”
23.1. Antecedentes
El 12 de febrero de 2005 en Madrid se produjo el incendio de uno de los edificios más altos
de la ciudad, la torre Windsor, este fue un fin de semana y quedó todo destruido. La torre
Windsor era un edificio de oficinas y en él tenían su sede varias empresas, incluyendo
alguna gran consultora.
Con motivo del incendio el edificio quedó inservible y empresas como la consultora De-
loitte que tenían allí sus oficinas debieron de buscar urgentemente otro sitio para poder
trabajar.
Esto que en principio es un gran problema, podría haber sido catastrófico de haberse
perdido toda la información de sus sistemas. Los servidores de la empresa (así como otras
muchas) se encontraban en el edificio y se perdió toda la documentación y toda la infor-
mación que había en ellos.
El problema de no haber tenido una copia de seguridad fuera del edificio podría haber
sido catastrófico. De hecho, tras el 11-S en Estados Unidos hubo empresas que debieron
de cerrar por idénticos motivos, perdieron sus sistemas, ya que estos se encontraban en
las torres gemelas y no tenían copia de seguridad por lo que prácticamente quedaron
abocadas al cierre.
Descuidar la atención al mantenimiento de unas mínimas garantías en la disponibili-

dad, confidencialidad e integridad de la información necesarias para el desarrollo de los
procesos críticos del negocio avoca a la ruina a todo tipo de organizaciones (grandes y
pequeñas) en términos de productividad, de reputación, de pérdidas financieras, de pér-
dida de competitividad en los mercados y/o exposición a multas por incumplimiento de
contratos y de la legislación relevante, tal y como podemos constatar en la prensa diaria.
En base a todas estas consideraciones podemos afirmar que “el conocimiento es poder”
cobra actualmente su sentido más amplio mediante las nuevas posibilidades en conecti-
vidad y accesibilidad a todo tipo de información en cualquier lugar y por todos aquellos
que integran la cadena de valor.
231
Las capacidades de accesibilidad a la información desde la propia movilidad de las per-

sonas han repercutido no sólo en la aparición de nuevos productos y servicios sino en la
desaparición y transformación de aquéllos considerados, en muchos casos, como tradi-
cionales e inalterables.
La sociedad industrial del pasado siglo ha dado paso a la sociedad de la información en la

que la creación, distribución y manipulación de la información forman parte importante
de las actividades culturales y económicas.
A diferencia de la sociedad industrial, la fortaleza de una organización ya no depende de

disponer de abundancia financiera o de capacidad recursos considerados básicos (por
ejemplo, maquinaria u otros bienes de inversión tradicionalmente de difícil acceso).
Es la información y su seguridad la que se ha convertido en el factor esencial para una

enorme gama de organizaciones, no sólo por su propia dependencia de la información
necesaria para el desarrollo de sus actividades, sino también por temas legales regulato-
rios y la confianza depositada por partes relevantes interesadas (accionistas, inversores,
suministradores, empleados, directivos, etc.) en estas organizaciones.
En el mundo en el que nos movemos hoy en día, por lo tanto, dentro de todo plan de sis-
temas dentro de la empresa, se deberá tener en cuenta la necesidad de contar con herra-
mientas de respaldo que permitan garantizar la continuidad del negocio en caso de algún
imprevisto, no ya únicamente de tipo informático (un virus, una caída del sistema, avería,
un empleado que intencionadamente o no borra archivos del sistema…) sino poder hacer
frente a sucesos más graves (incendio, robo, vandalismo, terremotos, inundaciones, etc.)
Un error muy habitual es almacenar los dispositivos de backup en lugares muy cercanos a
la sala de operaciones, cuando no en la misma sala. Esto puede parecer correcto y cómodo
si necesitamos restaurar unos archivos. Pero es un problema ya que ante un incendio que
reduce un edificio a cenizas, se nos unen dos problemas:
• El perder todos nuestros equipos, cosa que puede cubrir un seguro y no será tan
catastrófico.
• El perder también todos nuestros datos, tanto los almacenados en los discos como
los guardados en backups, que no cubre ningún seguro.
Como podemos ver, resulta recomendable guardar las copias de seguridad en una zona
alejada de la sala de servidores o equipos. Esto implica que tenemos que proteger el lugar
donde almacenamos los backups igual que protegemos la propia sala o los equipos situa-
dos en ella, algo que en ocasiones puede resultar caro.
También suele ser común etiquetar las cintas (o dispositivo de backup elegido) donde
hacemos copias de seguridad con abundante información sobre su contenido (sistemas
de ficheros almacenados, día y hora de la realización, sistema al que corresponde, etc.).
232
Esto tiene una parte positiva y una negativa. Por un lado, recuperar un fichero es rápido:
sólo tenemos que ir leyendo las etiquetas hasta encontrar la cinta adecuada. Sin embargo,
este tipo de etiquetado facilita a un intruso que consiga acceso a las cintas para sustraerla
con toda nuestra información, no necesitaría:
• Saltarse nuestro cortafuegos.
• Conseguir una clave del sistema.
• Chantajear a un operador.
• Elaborar complejos planes de ataque.
Nosotros mismos le estamos poniendo en bandeja todos nuestros datos.
No obstante, debemos elegir un sistema de etiquetado que permita identificar las cintas,
pero esa información nunca debe ser algo que le facilite la tarea a un atacante.
Se puede diseñar cierta codificación que sólo conozcan las personas responsables de las
copias de seguridad, de forma que cada cinta vaya convenientemente etiquetada, pero
que sin conocer el código sea difícil imaginar su contenido o cuyos códigos se mantengan
a buen recaudo.
Aunque en un caso extremo el atacante puede llevarse todos nuestros backups para ana-
lizarlos uno a uno, siempre es más difícil disimular una “carretilla” de dispositivos de
almacenamiento que una pequeña unidad guardada en un bolsillo.
Y si aún pensamos que alguien puede sustraer todas las copias, simplemente tenemos
que realizar backups cifrados y controlar más el acceso al lugar donde las guardamos.
23.2. Tecnologías de backup

En la actualidad, existen varias formas tecnologías diferentes a las que podemos realizar
el backup.
23.2.1. Backup a cinta

Es uno de los métodos más tradicionales de realizar el backup, este se realiza mediante el
software que hayamos elegido y es almacenado en una cinta magnética.
Tiene algunas ventajas, como el ser la cinta un soporte económico y que nos podremos
llevar de un sitio a otro, así a la hora de proteger nuestro backup y establecer que este no
se encuentre en nuestras oficinas, nos facilita mucho la tarea de tenerlo en un soporte
pequeño y perfectamente transportable.
233
La capacidad de las cintas varia, pero si queremos hacer copias de seguridad de grandes
cantidades de información, tenemos la opción de optar por robots de cintas, que se en-
cargan ellos mismos de ir sustituyendo las diferentes cintas o cartuchos según lo solicite,
por que estas se hayan llenado o estén alcanzando un sector crítico o por la política que
hayamos diseñado.
Las cintas pueden parecer una tecnología un poco obsoleta y antigua, pero sigue siendo
una de las tecnologías más utilizadas por su facilidad y bajo coste, que permite la movili-
dad y nos da una protección de los datos.
Por formato puede situarse como unidad interna en las maquinas o como soporte externo,
dependiendo del entorno donde nos encontremos.
La posibilidad de utilizar robots de cinta que funcionen de forma autónoma da mucha

flexibilidad al entorno ya que permite ser utilizado en entornos con grandes volúmenes
de datos sin problema.
El inconveniente de la cinta se presenta a la hora de la recuperación, es un entorno de

almacenamiento secuencial, esto quiere decir que los datos se escriben uno detrás de otro
y a la hora de recuperarlos, deberemos hacerlo de la misma forma o recorrer todos para
localizar el que nosotros queremos, lo cual, si hablamos de grandes cintas o múltiples,
puede alargar el proceso de localizar un dato concreto.
23.2.2 Backup a disco

Si bien las cintas es un entorno que permite el poder llevarnos la información y poder al-
macenarla, no es el entorno más rápido del mercado, por ello surge la posibilidad de hacer
backup contra un disco, que venga a reproducir la información que tenemos guardada en
nuestro sistema de almacenamiento, pero en formato de un backup, no será por lo tanto
un sistema que directamente podamos reutilizar, sino que a partir de los discos podamos
recuperar la información a nuestro almacenamiento.
A diferencia de un entorno de almacenamiento puro, en estos sistemas podemos utilizar

discos de mayor capacidad, ya que el rendimiento y el tiempo de respuesta no serán el
valor fundamental, sino la capacidad de almacenamiento.
Poder hacer las copias de respaldo contra entornos de discos nos permite la libertad de
poder tener un acceso más inmediato a los datos, poder hacerlo a una mayor velocidad y
permite aprovechar las ventajas de la escritura a disco.
Sin embargo, el inconveniente del backup a disco es que al tener un dispositivo de res-
paldo que se ha de mantener constante, no nos permite llevarnos las copas de seguridad
y por lo tanto seguir con la política de separar o alejar las copias de respaldo, siempre y
cuando el backup se haga en el mismo entorno donde se encuentran los datos.
234
Una solución positiva del backup a disco es poder utilizar la de-duplicación, que es esa
cualidad por la que el sistema al hacer backup repetidos tendremos los datos repetidos, lo
que hará aumentar los entornos en los que trabajamos.
La de-duplicación lo que nos permite es eliminar aquellos datos que vamos a almacenar
de forma repetida porque ya los tenemos dentro del sistema de almacenamiento.
Esta solución de la de-duplicación, nos permite ahorrar la capacidad de almacenamiento

que necesitamos, tener una solución lo más asequible posible nos puede permitir al mis-
mo tiempo mejorar.
Otra opción que tenemos haciendo el backup a disco es hacerlo de manera remota (esta
opción también existe con la cinta) que se podría tomar de dos formas, o bien replicando
el almacenamiento que tenemos en nuestra infraestructura principal y realizando una
copia exacta que se puede ir rehaciendo de manera sincronizada o de manera asíncrona
(muchas veces la opción depende de la velocidad de comunicación y el retardo entre
nuestras diferentes sedes). La segunda forma sería hacer el backup, pero tomando que el
dispositivo de destino se encuentra en esa posición remota que nos garantiza que en caso
de incidente en nuestra sede principal sigamos teniendo todos los datos.
23.2.3 Software de backup

A la hora de realizar el backup de nuestros sistemas, no solo debemos contar con un en-
torno donde poder hacer la copia de seguridad, sino también con un software que nos lo
permita, existen numerosas soluciones en el mercado, y cada una funciona de una forma
distinta.
Deberemos evaluar que funcionalidades nos ofrece, así como el entorno del cual vayamos
a hacer la copia de seguridad. No es lo mismo realizar copias de seguridad de entornos
con bases de datos que de sistemas de virtualización, ya que, en muchas ocasiones, para
que la copia de seguridad sea lo más efectiva posible, contaremos con un agente dentro
de la aplicación que será quien se encargue de recopilar los datos necesarios.
En muchas ocasiones los propios sistemas operativos ya incluyen soluciones básicas para
las copias de seguridad, pero según nuestra infraestructura y las necesidades será mejor
optar por una solución especifica.
Otra opción es que el propio hardware de backup incorpore su software para ayudarnos a
realizar las copias de respaldo de nuestros sistemas.
Para evaluar, es importante la compatibilidad completa entre el software, el hardware y los

sistemas de los cuales queramos hacer la copia de respaldo, por ello deberemos compara
y contrastar.
235
23.3. Politica de seguridad en los backup

Para la realización correcta de un sistema de respaldo, tendremos que tener en cuenta
numerosos factores.
23.3.1 Horario
Realizar una copia de seguridad de nuestros sistemas lleva tiempo y generalmente ralen-
tiza su ejecución, es por ello aconsejable realizarlos en los momentos de menos carga de
trabajo.
En ocasiones, según el sistema del que estemos haciendo el backup se puede realizar un
snapshot (una foto fija del entorno en su estado actual) del que se irá haciendo backup y
mientras seguiremos trabajando.
Otra opción es realizar durante los fines de semana una copia de respaldo completa y
luego diariamente solo haremos uno incremental (aquel que almacena los cambios que
se han producido entre una y otra vez).
De esta forma la productividad y el rendimiento de nuestros sistemas no será afectado y

podremos trabajar con normalidad, sabiendo que tenemos los datos preparados al último
momento.
23.3.2 Validación autentificación

Cuando estamos realizando una copia de seguridad en ocasiones deberemos acceder a
sistemas, aplicaciones o datos que pueden encontrarse bloqueados con contraseña o que
se encuentran codificados. Deberemos de garantizar que nuestro sistema de backup tiene
los permisos adecuados y los accesos a los sistemas necesarios para poder hacer la copia
de respaldo de los elementos que marquemos y que queramos proteger.
Una vez realizada la copia, está puede ser también cifrada o codificada según las necesi-
dades que tengamos en cada momento.
Una práctica correcta dentro del establecimiento de las políticas de respaldo sería el rea-
lizar comprobaciones periódicas de que todo se está haciendo correctamente y que tene-
mos todos los datos que queremos guardados y protegidos.
Es bastante común que en un momento dado la cinta o el entorno donde estemos hacien-
do el backup se llene y nos quedemos sin capacidad suficiente para guardar los datos, o
queramos hacer una copia de seguridad de más elementos que los que nos encajan en
nuestro sistema de backup.
236
En ocasiones se ha dado también la situación de que se produjo un error en una solución

de backup y como damos por hecho que se ejecuta de forma periódica sin nuestra super-
visión, nadie lo ha detectado y lo vemos cuando necesitamos recuperar alguna informa-
ción y esta no se encuentra correctamente almacenada.
Por lo tanto, la comprobación de la integridad de los datos es un elemento importante.
23.4. Conclusiones
La realización de copias de seguridad o de respaldo es un elemento imprescindible en la
empresa de hoy en día, donde la información es poder.
Existen en el mercado diferentes tecnologías y soluciones para poder realizar estas copias
y ayudarnos a garantizar que nuestros datos están seguros.
Realizar una copia de seguridad no es garantía de tener los datos, pero incremente enor-
memente las probabilidades de ser capaces de recuperarnos frente a una avería o una
catástrofe.
Hemos de establecer un plan de seguridad en la empresa que nos permita protegernos y

nos ayude a seguir trabajando en caso de problemas o inconvenientes.
La información, incluso por motivos legales, de las empresas debe de estar correctamente
almacenada y custodiada, por todo esto es importante realizar las copias, comprobarlas, y
tener una solución para continuar con nuestro día a día.
Es importante destacar que si bien la creación de los backup es algo útil y necesario en
la empresa de hoy, es también necesario realizar procesos periódicos de simulación de
pérdida de datos, ya que de nada vale realizar copias de entornos, aplicaciones, bases de
datos, si en el momento en que perdemos algo no sabemos el protocolo de recuperación
(por muy segura que sea nuestra política ) que es la que nos va a decir si hay que redefinir
las pautas de seguridad o modificar las herramientas de backup.
237

Las diferentes tecnologías para hacer backup:
• Backup a disco.
• Backup a cinta.
• Software de backup.
Cómo establecer una política de backup teniendo en cuenta elementos como la seguri-
dad, los horarios, el acceso a los sistemas, que las copias de seguridad sean almacenadas
si es pertinente en diferentes entornos de donde estemos trabajando y como garantizar la
recuperación después de realizar un backup.
Dato importante
A la hora de realizar el backup de nuestros sistemas, no solo debemos contar con un

entorno donde poder hacer la copia de seguridad, sino también con un software que
nos lo permita, existen numerosas soluciones en el mercado, y cada una funciona de
una forma distinta. Deberemos evaluar que funcionalidades nos ofrece, así como el
entorno del cual vayamos a hacer la copia de seguridad.
238
24. Historia del desarrollo e

integración de sistemas
“Gracias al auge de la telefonía móvil se han abierto nuevas puer-
tas para el desarrollo de todo tipo de aplicaciones. En este mercado,
encontramos a los tres grandes, Apple, Microsoft y Google, con sus
diferentes alternativas.”
24.1. Introducción al desarrollo e integración de sistemas

A la hora de emprender un proyecto de desarrollo, nos encontramos con que se ha de
decidir cuál será la arquitectura de dicho proyecto, y asaltan multitud de dudas, ¿qué
lenguaje usaremos?, ¿cuál será el entorno de desarrollo?, ¿usaremos algún tipo de meto-
dología y, si es así, cuál? Si intentamos contestar sin una reflexión previa, podemos llevar
a mal puerto nuestro proyecto.
Para poner un ejemplo de lo complejo que puede ser contestar estas preguntas, intentare-
mos responder la primera de todas ellas: ¿qué lenguaje usaremos?
Teniendo en cuenta que el número de lenguajes se cuenta por varios centenares (se calcu-
la cerca de 700 tipos entre variantes y originales), se complica enormemente la decisión.
De todo el abanico de posibilidades, tendremos que tener en cuenta:
• Si queremos que sea portable entre diferentes plataformas.
• Si queremos que esté optimizado para un sistema en concreto.
• Si queremos que se entienda con una determinada tecnología.
• Si queremos que facilite la implementación de sistemas de inteligencia artificial.
• Si queremos que funcione en plataformas móviles.
• Si es adecuado para dar soporte al patrón de desarrollo que se quiere usar.
• Si encontraremos soporte.
Así, un largo etcétera de cuestiones nos puede complicar la decisión.
239
Otras cuestiones vitales para decidirnos son: ¿tenemos dentro de nuestra organización
alguien que conozca este lenguaje de programación?, ¿cuánto cuesta el perfil de alguien
que domine este lenguaje? Estos factores van más allá de lo técnico y pueden encarecer
mucho el proyecto.
La elección de cualquier elemento que intervenga en nuestros proyectos de desarrollo

puede tener mil variables que han de ser analizadas con sumo cuidado desde el inicio
para evitar las sorpresas en el futuro.
Un tipo de proyecto de desarrollo muy habitual en organizaciones, sobre todo en aquéllas

que tienen una cantidad considerable de sistemas diferentes, son los de integración de
sistemas. Éstos básicamente realizan tareas para comunicar dos o más sistemas diferen-
tes mediante una serie de interfaces estándar o creadas por los equipos de desarrollo.
Seguramente este tipo de desarrollo no sería necesario, al menos internamente, pero por
imperativos funcionales no siempre se dispone de un paquete que cubra todas las nece-
sidades de la empresa y es necesario comunicar nuestro sistema de nóminas con nuestro
BPM, o la comunicación del CRM con nuestro portal del empleado para dar algún servicio
suplementario.
Pese a que en muchas organizaciones estos desarrollos, a veces, son vistos como peque-
ñas setas (desarrollos a medida que en muchas ocasiones no se saben quién los creó), en
ocasiones nos puede ahorrar mucho dinero. La clave está en cómo organizarlos y cómo
evitar que se descontrolen.
Otra variante es los desarrollos de integración de sistemas hechos por imperativo de la

funcionalidad. Por ejemplo, podemos tener un proveedor que nos da servicio a través de
un web service y tenemos que realizar un desarrollo para interactuar con los servicios que
nos proporciona. Otra situación que se puede dar es tener que comunicar nuestro sistema
con un hardware específico que se encuentra fuera de nuestra red.
El número de escenarios donde podemos aplicar un desarrollo para integrar diferentes

sistemas es enorme. Para esto, existen multitud de patrones de diseño, según la funcio-
nalidad buscada. Para que nos hagamos una idea de un proyecto de este tipo podemos
pensar en la típica web que realiza una consulta a través de un servicio de lista de morosos
que, por norma general, suelen funcionar a través de web services seguros, o las pasarelas
de pagos que ofrecen servicios financieros a las tiendas online.
240
24.2. Historia
Podemos decir que la historia del desarrollo no se remonta mucho en el tiempo. Pese a ser
una disciplina relativamente nueva y que avanza a gran velocidad, se remonta a unos cien
años atrás, donde los científicos de la época se esmeraban por conseguir formalizar de
alguna forma los procesos que intervenían a la hora de aplicar un determinado algoritmo.
Por ese entonces, no había máquinas que pudieran dar soporte a este tipo de lenguajes,
pero poco a poco se fue avanzando lo suficiente como para crearlas y poder ejecutar estos
lenguajes.
Podemos distinguir varias etapas en la evolución del desarrollo.
24.2.1. Primer periodo

Es este primer periodo, lo importante son las máquinas. Se trata de la época de los prime-
ros ordenadores capaces de realizar tareas básicas y rudimentarias. Éstos eran grandes
moles y no tenían propósitos de uso personal, sino que se usaban para fines científicos,
militares y dentro de alguna gran empresa.
De las primeras máquinas, destacan:
• EDSAC: desarrollado por la Universidad de Cambridge.
• ENIAC: puesto en marcha en 1946. La primera máquina de propósito general. Pe-

saba unas 27 toneladas y ocupaba una superficie de 63 m2.
• Colossus: puesta en servicio en 1944. Se usó en la Segunda Guerra Mundial para

descifrar los códigos secretos de los alemanes. Era un complemento a las grandes
moles existentes, pues en esta etapa no se daba importancia al desarrollo de aplica-
ciones. No existía planificación alguna, las aplicaciones eran hechas con lenguajes
rudimentarios, muchas veces en el propio código máquina, difícil de entender y
depurar en caso de errores. El software se diseñaba a medida para las aplicaciones
y tenían muy poca difusión a causa del reducido número de máquinas existentes
en el mundo. No existían casi estándares y mucho menos se usaban metodologías
o patrones de desarrollo. Curiosamente, durante esta época era sencillo retener a
los desarrolladores, puesto que el número de empresas que disponían de este tipo
de tecnología era limitado y no era sencillo cambiar de empresa.
241
24.2.2. Segundo periodo

Este periodo se extiende desde la década de los sesenta a mediados de los setenta. En esta
época, apareció el concepto de sistema multiusuario y el hardware permitió interactuar de
otra forma con las máquinas.
Se empezaron a difundir diferentes sistemas y cada vez más organizaciones empezaron a

tener máquinas propias sin tener que ser grandes multinacionales. El desarrollo empezó a
despuntar como disciplina. La gran cantidad de máquinas y las grandes posibilidades que
éstas ofrecían llevaron a la creación de todo tipo de software para tareas diversas. Cada
compañía empezó a realizar sus desarrollos, pero sin seguir ningún tipo de metodología o
estándar; esto hacía que el software fuera muy dependiente de la máquina destino, por lo
que se tenían que realizar grandes esfuerzos para cualquier tipo de mantenimiento.
Esta situación en la que cada cual tenía su método llevó a lo que se conoció como a “la
crisis del software”.
24.2.3. Tercer periodo

El tercer periodo empezó a mediado de los años setenta y se extendió más de una década.
El avance del hardware hizo que las máquinas empezaran a comunicarse y que ejecutaran
funciones de forma concurrente, lo que incrementó la complejidad de los desarrollos. El
uso personal de las computadoras aún era poco común y se limitaba casi exclusivamente
al ámbito académico y empresarial. En estos entornos, crecía la demanda de acceso en
tiempo real de la información, lo que supuso que el software se volviera más complejo,
traspasando la presión al mundo del desarrollo, que aún estaba superando los problemas
de la crisis del software de la etapa anterior.
Durante esta etapa y gracias a los avances producidos en la electrónica digital, se empe-
zó a popularizar el uso de microprocesadores, lo que cambiaría la forma de concebir los
desarrollos y facilitaría enormemente la creación de aplicaciones gracias a sus juegos de
instrucciones estandarizados.
Otro acontecimiento que también impactaría en el mundo del desarrollo es la creación

de la red militar ARPANET, una red de comunicaciones con capacidad para soportar la
pérdida de nodos sin perder conectividad, por ello se convertiría más adelante en la base
del actual internet.
242
24.2.4. Cuarto periodo

Este periodo es uno de los más largos y en el que más sucesos podemos encontrar. Se
sucede desde principios de los años ochenta hasta principio del 2000.
Se empezaron a popularizar los ordenadores personales y diversas compañías aún exis-

tentes, como Apple o IBM, popularizaron sus sistemas personales para uso en el hogar.
Pese a la existencia de otras plataformas personales, como fueron los ordenadores Amiga
o Atari, sin duda fue una etapa dominada por los sistemas PC, que tenían como base mi-
croprocesadores de la gama 8086, diseñados en la etapa anterior por Intel, y que estable-
cieron las bases de los ordenadores personales que actualmente conocemos.
En esta etapa, gracias a la popularización de los ordenadores personales, cada vez fue
más frecuente que la gente dispusiera de un ordenador con que poder hacer todo tipo de
tareas (entre ellas, programar su propio software). Esto facilitó el acceso a tecnologías que
previamente habían estado dominadas por el entorno académico y el entorno empresa-
rial.
También en esta etapa aparecen los primeros sistemas operativos orientados al gran pú-
blico, como el DOS, MacOS o el actual Windows que hacían mucho más accesible el uso
de los ordenadores personales.
Otro gran acontecimiento en esta etapa es la explosión de internet, que fomentó el in-
tercambio de información entre los usuarios, poniendo a disposición de todo el mundo
cantidades ingentes de conocimiento.
Todos estos acontecimientos son la base del crecimiento del mundo del software. En esta
etapa, se empezaron a crear los primeros lenguajes orientados a objetos, dejando atrás la
antigua programación procedural. Se empezaron a popularizar los patrones de desarrollo
y el uso de patrones de diseño, lo que hacía más sencillo el mantenimiento, evolución y
posterior portado de las aplicaciones entre plataformas. Todo esto da paso a la creación
de nuevos lenguajes de programación de más alto nivel, como Java, lo que facilitó que
un programa (independientemente de la máquina donde fuera programado) se pudiera
ejecutar, sin tener prácticamente que hacer nada, con máquinas de diferente arquitectura
o sistemas operativos diferentes.
En esta etapa y gracias al auge de internet, se empezaron a popularizar los lenguajes de

programación orientados al desarrollo web; también muchos de los antiguos lenguajes
empezaron a adaptarse para dar soporte al desarrollo web, preparándose para la gran
avalancha de negocio que internet traería gracias a su creciente popularidad.
243
En esta etapa, encontramos uno de los peores momentos de la industria del software, la
burbuja de las .com. Las causas que llevaron a esta grave crisis fueron dos:
• Las empresas contrataron gran cantidad de empleados para adaptar sus antiguos
sistemas al cambio de milenio, pagando cifras exorbitadas, lo que hizo que una vez
pasado el 2000 se encontraran con departamentos enteros muy bien pagados con
los cuales no sabían qué hacer. Finalmente, se optó por el cierre de las áreas y los
despidos masivos.
• El crecimiento de internet: todas las empresas quisieron estar en internet bajo la

promesa de que esto les repercutiría en su cuenta de resultados generosamente. Se
hicieron verdaderas barbaridades durante esta época, vendiendo sistemas a pre-
cio de oro y cobrando las horas de consultoría muy por encima del coste real de
los servicios prestados. Los proyectos de integración se cobraban muy caros y se
hacían en plazos de tiempo muy largos. Llegado el momento de ver los beneficios
de todo este gasto sin sentido, se observó que realmente que por el simple hecho
de tener una web o una tienda en internet la empresa no vendería diez veces más;
esto también desembocó en el cierre de áreas completas y multitud de despidos.
24.2.5. Actual periodo

En este periodo, cuyo inicio se podría establecer a mediados de la primera década del año
2000, pese a la gran crisis de las .com y la gran contracción del mercado por la crisis, no se
ha dejado de avanzar: gracias al auge de la telefonía móvil se han abierto nuevas puertas
para el desarrollo de todo tipo de aplicaciones. En este mercado, encontramos a los tres
grandes (Apple, Microsoft y Google) con sus diferentes alternativas.
También se está popularizando el cloud computing y el desarrollo para esta tecnología

que es rompedor, porque pasamos de un modelo de aplicaciones nativas para la máquina
o desarrollos web alojados en nuestros servidores a tener plataformas totalmente inde-
pendientes de hardware y accesibles desde cualquier sitio.
Dato importante
Durante el cuarto periodo, se popularizan los ordenadores personales, aparecen

los primeros sistemas operativos orientados al gran público, como el actual Win-
dows, que hacían mucho más accesibles el uso de los mencionados PCs y llega la
explosión de Internet, que fomentó el ingente intercambio de información entre los
usuarios. Estos acontecimientos son la base del crecimiento del mundo del software.
244

En esta unidad didáctica, se ha podido ver:
• Introducción al mundo del desarrollo:
• Factores de un proyecto de desarrollo.
• Integración de sistemas.
• Historia del software:
• Primera etapa: dominada y centralizada en el hardware de las grandes máquinas.
• Segunda etapa: primeros pasos hacia de desarrollo de la ciencia de la computa-

ción.
• Tercera etapa: incremento de la complejidad del desarrollo.
• Cuarta etapa: explosión del uso de internet y del desarrollo.
• Etapa actual: incremento de las aplicaciones móviles y del cloud computing.
245
25. Lenguajes de programación

“En la actualidad, predominan los lenguajes de alto nivel y la pro-
gramación orientada a objetos, que lleva usándose ampliamente
desde los años ochenta. Este paradigma de programación ha guia-
do durante mucho tiempo el avance de los lenguajes.”
25.1. Historia
La programación se debe al trabajo de Ada Lovelance, que publicó sus primeras notas
relacionadas con la calculadora mecánica de Charles Babbage. A ella, se le acredita haber
escrito el primer programa de computación en 1843.
Más adelante, en las primeras máquinas que se construyeron en torno a los años cuarenta,
la programación se realizaba de forma manual, conectando cables y activando interrupto-
res. Los datos eran suministrados mediante tarjetas perforadas. Estas tarjetas perforadas
eran creadas por los programadores de la época; teniendo en cuenta la dificultad de codi-
ficar las instrucciones en este tipo de soportes, nos podemos hacer una idea que hasta el
cálculo más básico se convertía en una tarea que consumía mucho tiempo.
Poco después, con los avances producidos en la rama de computación y en la fabricación

de hardware, los desarrollos avanzaron hacia lo que se llamaba lenguaje máquina. Este
lenguaje no era más que secuencias de unos y ceros que indicaban cuando un interruptor
tenía que estar encendido o apagado.
A principios de los años cincuenta, empezaron a aparecer los primeros lenguajes sim-
bólicos, llamados así porque venían a intentar paliar el principal problema del lenguaje
máquina, su legibilidad. De esta forma, los lenguajes estaban formados por términos más
fáciles de recordar y con cierto significado que ayudaba a su comprensión, por ejemplo, se
podían encontrar instrucciones como MUL (multiplicar), ADD (sumar), SUB (restar), etc.
Este tipo de lenguajes se llamaban lenguajes ensambladores.
Entre los años cincuenta y sesenta, aparecieron los primeros lenguajes de alto nivel.
Éstos estaban formados por una serie limitada de instrucciones, una gramática y una
sintaxis que relativamente hacia que el lenguaje se fuera asemejando cada vez más al
lenguaje natural.
246
Pese a estos avances, los lenguajes de alto nivel son abstracciones de un lenguaje de
más bajo nivel. Cuando un desarrollador realiza un programa, éste, antes de poder ser
ejecutado uno de los pasos, se pasa por un traductor (compilador) que convierte el código
en lenguaje máquina o ensamblador, que son realmente los lenguajes que entienden los
microprocesadores.
Entre los lenguajes más antiguos, se encuentran:
• C: creado por K. Thompson y D. Ritchie.
• FORTRAN: creado por J. Backus.
• Cobol: creador en 1960 por G. Hopper.
• Pascal: creado en 1970 por N. Wirth.
• IBM RPG: creado en 1959 por IBM.
En la actualidad, predominan los lenguajes de alto nivel y la programación orientada a

objetos, que lleva usándose ampliamente desde los años ochenta. Este paradigma de pro-
gramación ha guiado durante mucho tiempo el avance de los lenguajes, se han creado
numerosos lenguajes para dar soporte a este paradigma de desarrollo y otros antiguos
han sufrido cambios en sus especificaciones posteriores para poder dar soporte.
25.2. Definición y clasificación

Un lenguaje de programación es un conjunto de símbolos, reglas semánticas y reglas sin-
tácticas que conforman una estructura válida y el significado de sus términos. Su fin últi-
mo es el de controlar el comportamiento de un hardware, tanto a nivel físico como lógico.
Cuando hablamos de lenguaje de programación, hay tres elementos importantes que ca-
racterizan todos los lenguajes:
• Instrucciones: básicamente, los comandos que conforman un lenguaje de progra-

mación, lo que en lenguaje natural son las palabras.
• Sintaxis: cómo se escriben los términos que conforman el lenguaje y define lo que
son, si son instrucciones, variables, condiciones, etc.
• Gramática: reglas que definen cómo los términos de un lenguaje se unen para con-
formar una estructura con sentido.
247
Los lenguajes de programación se pueden clasificar en función de ciertas propiedades.

Las más importantes son:
• El nivel de abstracción. Esto hace referencia al nivel del lenguaje. Conforme más se
acerque al lenguaje natural, mayor será su nivel de abstracción:
• Máquina y bajo nivel. Los microprocesadores actuales utilizan el código máqui-

na. Por encima, tiene una capa de abstracción que es el ensamblador. Desarro-
llar en este tipo de lenguajes de tan bajo nivel es altamente complicado por su
dificultad implícita, eso no quita que haya gente que lo use si es necesario. La
ventaja de usar un lenguaje a tan bajo nivel es que casi no hay limitaciones a
lo que se quiera hacer y se tiene un control casi total de la máquina. Lo malo
es la tremenda dificultad que entraña hacer cualquier cosa, los tiempos de de-
sarrollo se disparan. Es muy poco legible y hasta el ensamblador que está algo
más humanizado es complicado de entender para los que no sean muy expertos.
Además, está totalmente ligado al tipo de microprocesador de la máquina, con
lo cual es prácticamente imposible de portar con velocidad a otras arquitecturas.
• Medio nivel. Se encuentra algunos lenguajes que están a medio camino entre
los lenguajes de alto nivel y los de bajo nivel. Como puede ser el lenguaje C, que
nos permite gestionar la memoria o los registros del microprocesador, o acceder
a otros elementos que otros lenguajes enmascaran al desarrollador para facilitar
su tarea de desarrollo. Pese a este control del bajo nivel, el lenguaje proporciona
instrucciones, sintaxis y gramática de alto nivel.
• Alto nivel. Se acercan más a la forma de expresión natural, el lenguaje natural.

Se caracterizan por expresar los algoritmos de una manera que facilita su inter-
pretación para el ser humano, en lugar de estar orientado a la interpretación di-
recta de la máquina. Los inconvenientes de este tipo de lenguajes es que al final
muchos de los procesos necesarios para que la máquina funcione son enmasca-
rados por el lenguaje con el fin de facilitar su uso, la pérdida de control sobre el
hardware en la gran mayoría de casos se compensa y de ahí su amplia difusión.
Destacamos como ventajas que es legible y mucho más fácil de mantener; pues-
to que está un nivel por encima de abstracción del lenguaje ensamblador, es
posible portarlo a otro tipo de arquitectura con pocos o ningún cambio.
• Muy alto nivel. Tienen como fin intentar que el usuario sin conocimientos de
desarrollo pueda realizar programas que le ayuden a solucionar tareas concretas.
248
• La forma de ejecución: los lenguajes de alto nivel se pueden ejecutar de dos formas:
• Compilados. Cuando se crea un desarrollo en un lenguaje de alto nivel, éste no

es entendible por la máquina de forma directa, lo que implica que para que el
lenguaje pueda ser ejecutado ha de pasar por varios procesos; uno de los más im-
portantes es un proceso de traducción donde un programa llamado compilador
se encarga de convertir este código de alto nivel en otro que el microprocesador
de la máquina pueda ejecutar sin problemas.
De esta forma, se pasa del código fuente al binario, que se ejecutará en la máqui-
na destino. Las ventajas de los lenguajes compilados son:
• Se compila una vez y se utiliza todas las veces que sea necesario, sin tener que
volver a ser compilado.
• Los compiladores no sólo realizan la tarea de traducción, sino que se aseguran

de que se cumplen todas las reglas que el lenguaje establece. De esta forma, se
produce una detección temprana de muchos de los errores que se producen
en la fase de codificación.
• Es más eficiente que los interpretados.
• Interpretados. Hay lenguajes de programación que se limitan a tener un intér-

prete que va procesando línea por línea el código, interpreta la línea y la convier-
te en código máquina para su ejecución.
De esta forma, no hay proceso de compilación, pero el rendimiento es mucho

menor y se ha de disponer del código fuente para que se pueda ejecutar. Las
ventajas de un lenguaje interpretado son:
• Al contrario que los compilados, es independiente de la arquitectura. Si un

binario se quiere ejecutar en otra arquitectura, tendrá que ser compilado de
manera específica para esa arquitectura, mientas que el interpretado, gracias
al intérprete, funcionará igual en una arquitectura que en otra.
• Los lenguajes interpretados son más sencillos de empaquetar dentro de otros

lenguajes.
249
• El paradigma de programación que posee:
• Algorítmico, imperativo o por procedimiento. Este paradigma describe la pro-

gramación en términos de estados del programa y sentencias que cambian di-
chos estados. Los programas imperativos son un conjunto de instrucciones que
indican al hardware cómo tiene que realizar una tarea. La mayoría de las arqui-
tecturas de los ordenadores son imperativas, puesto que el hardware está dise-
ñado para aceptar instrucciones de forma imperativa.
• Declarativo o predicativo. Este paradigma está basado en la utilización de pre-

dicados lógicos o funciones matemáticas. El fin de este tipo de lenguajes no es
enseñar al hardware cómo se ha de resolver un determinado problema, sino qué
clase de problemas se quieren resolver. Este tipo de lenguajes, al final, se basan
en un motor de inferencia que procesa los predicados. Estos lenguajes son muy
comunes en campos como la inteligencia artificial, por su facilidad para manejar
la incertidumbre de los problemas.
• Programación Orientada a Objetos (POO). En la actualidad, este paradigma es

el más utilizado y muchos de los lenguajes comerciales le dan soporte. Estos len-
guajes utilizan una mezcla de orientación a objetos y programación imperativa.
Este paradigma es complejo de entender por la cantidad de herramientas que
da para modelar la realidad y llevarla a expresar lo que se quiere en código; pero
pese a su complejidad inicial, luego ofrece grandes ventajas una vez se domi-
na. Este paradigma utiliza herramientas soportadas por los lenguajes actuales,
como herencia, polimorfismo, herencia múltiple, sobrecarga, etc.
• Programación Orientada a Aspectos (POA). Este paradigma es bastante recien-

te y busca permitir la adecuada modularización de los aplicativos, posibilitando
una mejor separación de ámbitos. De esta forma, se puede separar en una apli-
cación, por ejemplo, de todo el proceso de loggin, sin que existan dependencias
entre los módulos que conforman el aplicativo.
Dato importante
A principios de los años cincuenta, empezaron a aparecer los primeros lenguajes

simbólicos, llamados así porque venían a intentar paliar el principal problema del
lenguaje máquina; su legibilidad. De esta forma, los lenguajes estaban formados
por términos más fáciles de recordar y con cierto significado que ayudaba a su com-
prensión, por ejemplo, MUL (multiplicar), etc. Este tipo de lenguajes se llamaban
lenguajes ensambladores.
250
25.3. Lenguajes
Son muchos los lenguajes que nos podemos encontrar en el ámbito del desarrollo, pero
los más utilizados actualmente son:
• Java. Es un lenguaje de programación orientado a objetos, desarrollado por J.

Gosling en 1995. Su sintaxis se basa en gran medida en la sintaxis de C, Cobol y
Visual Basic. Tiene un modelo de objeto más simple, eliminando la herencia múl-
tiple. También elimina cualquier herramienta de bajo nivel como el acceso directo
a memoria, que suelen inducir a muchos errores. Además, gestiona la memoria a
través de un recolector de basura, que es un proceso activo durante la ejecución
del programa que se encarga de eliminar los objetos que ya no se usan, poniendo a
disposición del sistema la memoria ocupada. Una de las características más impor-
tantes es que las aplicaciones están compiladas en un bytecode, interpretado por
una máquina virtual que corre sobre el sistema original y hace portable el código.
• C. Es un lenguaje de programación creado en 1972 por D. M. Ritchie en los labo-

ratorios Bell como evolución del anterior lenguaje B. C es considerado un lengua-
je de medio nivel porque, pese a tener la estructura de un lenguaje de alto nivel,
provee de muchas herramientas que le permiten acceso a bajo nivel. Al contrario
que otros lenguajes como Java, la gestión de memoria queda de la mano del desa-
rrollador y se tiene acceso a ella sin ninguna restricción más que la que ponga el
sistema operativo.
Uno de los objetivos de diseño del lenguaje C es que sólo sean necesarios unas po-
cas instrucciones en lenguaje máquina para traducir cada elemento del lenguaje,
lo que le confiere una gran velocidad. En muchas ocasiones, el lenguaje C se utiliza
como lenguaje intermedio entre uno de alto nivel y el bajo nivel.
• C++. Es un lenguaje de programación diseñado a mediados de los años ochenta por

B. Stroustrup. La intención principal fue extender el lenguaje C con mecanismos
que le permitieran la manipulación de objetos. Es la extensión de C para dar sopor-
te a paradigmas de la orientación a objetos.
De hecho, es considerado como el que mayor soporte a este paradigma da y permi-

te muchas de las herramientas que otros no permiten, como puede ser la herencia
múltiple, concepto complicado de implementar pero que C++ lo hace perfectamen-
te.
251
• Objective C. Es un lenguaje de programación creado como un súper conjunto de C

para implementar un modelo de objetos parecido al de Smalltalk. Fue creado por B.
Cox y la corporación StepStone en 1980. En 1988, fue adoptado como lenguaje de
programación de NEXTSTEP y en 1992 fue liberado bajo licencia GPL para el com-
pilador GCC. En la actualidad, se utiliza como lenguaje principal de programación
en todos los entornos de Apple, en su sistema operativo Mac OS e IOS.
• C#. Se lee como C Sharp. Es un lenguaje de programación orientado a objetos,

desarrollado y estandarizado por Microsoft como parte de framework.net. Su sin-
taxis básica deriva de C/C++ y utiliza el modelo de objetos de la plataforma .net;
tiene grandes similitudes con Java e incluye muchas mejoras derivadas de otros
lenguajes.
25.4. Actualidad y tendencias

El índice comunitario de programación (TIOBE) publica anualmente su ranking de len-
guajes más utilizados por los desarrolladores. En éste podemos ver como el lenguaje más
utilizado en 2012 es el C y como Java, pese a perder su liderazgo, se mantiene en las pri-
meras posiciones.
También se puede ver cómo, a causa del gran crecimiento de creación de aplicaciones
para dispositivos IOS de Apple, Objective-C lleva subiendo posiciones varios años, pa-
sando de ser un lenguaje casi minoritario a uno de los más reclamados actualmente. Está
claro que los dispositivos móviles están revolucionando el panorama y las aplicaciones
móviles son gran parte de esta revolución, por lo tanto, conforme vayan saliendo nuevas
plataformas, posiblemente se irán no sólo popularizando, sino aupando nuevos lenguajes
de programación.

• Historia:
• Primer programa en 1843.
• Evolución de los lenguajes: código máquina, ensamblador, etc.
• Dominio de los lenguajes orientados a objetos.
252
• Definición y clasificación:
• Instrucciones, sintaxis y gramática.
• Nivel de abstracción: bajo nivel, medio nivel, alto nivel y muy alto nivel.
• Forma de ejecución: compilado e interpretado.
• Paradigma de programación: imperativo, predicativo, orientado a objetos y

orientado a aspectos.
• Lenguajes de programación: C, C++, Java, etc.
• Nivel de abstracción: bajo nivel, medio nivel, alto nivel y muy alto nivel.
• Forma de ejecución: compilado e interpretado.
• Paradigma de programación: imperativo, predicativo, orientado a objetos y

orientado a aspectos.
253
26. Metodologías de desarrollo

“A causa de que el software que se realiza o crea la gran mayoría
de veces forma parte de un sistema más grande, el trabajo ha de
empezar estableciendo los requisitos de todos los elementos que lo
conforman y las interacciones que nuestro nuevo software tendrá
con ellos.”
26.1. Introducción a las metodologías de desarrollo

El desarrollo de software tradicional de ciclo de vida se originó en los años sesenta para
cubrir la demanda cada vez más creciente de desarrollo software en las grandes empresas,
que por aquel entonces eran las que tenía acceso al mundo de la computación.
Una metodología de desarrollo es un marco de trabajo que nos ofrece una serie de he-
rramientas para la gestión de un proyecto software en cada una de sus fases, también
llamado ciclo de vida.
La solicitidud del Lo que entendió el líder El diseño del analista El enfoque del La recomendación del
usuario del proyecto de sistemas programador consultor externo
254
La documentación del La implantación en El presupuesto del El soporte operativo Lo que el usuario real-
proyecto producción proyecto mente necesitaba
Figuras 1 y 2. Realidad de la creación de software.
Este gráfico define perfectamente la realidad de lo que sucede en un gran porcentaje de

proyectos software, nos muestra la cantidad de puntos de vistas que hay y cómo el no
estar perfectamente alineados puede producir desviaciones que acaban por llevar un pro-
yecto al fracaso.
Por tanto, la buena elección de la metodología, siempre teniendo en cuenta las peculiari-
dades del proyecto a realizar, puede evitar muchos de los problemas que aparecen duran-
te el ciclo de vida del proyecto.
Pros del uso de una metodología:
• Mejora en la gestión del desarrollo.
• Control y corrección de las desviaciones.
• Facilidad en la creación de documentación.
• Facilidad en la realización de evolutivos.
• Facilidad en la realización de mantenimientos.
• Facilidad en la medición de los progresos.
• Descenso en la dependencia del equipo de desarrollo.
255
Contras del uso de una metodología:
• Exceso de documentación que, a menudo, puede ser poco práctica.
• Incremento de la burocracia en la gestión de proyectos.
• En ocasiones, pérdida de la flexibilidad y la agilidad a la hora de enfrentarse a

cambios inesperados.
Con el tiempo, las metodologías de desarrollo han ido evolucionando gracias a un proce-
so constante de revisión; también con el tiempo han ido apareciendo nuevas metodolo-
gías, buscando paliar los contras de las metodologías tradicionales, centrándose en dar
más agilidad en el desarrollo y desechando mucha de la burocracia. Estas son las denomi-
nadas metodologías ágiles.
26.2. Tipos de metodologías

Podemos dividir las metodologías en tres tipos:
• Lineal. Este tipo de metodología encadena todas sus fases, de forma que no se
puede empezar una fase hasta no haber terminado por completo la anterior. Por
ejemplo, la metodología en cascada.
• Iterativa. Este tipo de metodología produce interacción entre las diferentes etapas,
una vez terminado un ciclo completo, éste puede volver a empezar por el principio,
entrando en un círculo de revisión constante. Por ejemplo, la metodología de pro-
totipo o la metodología RAD.
• Lineal-iterativa. Este tipo de metodología es una mezcla de las dos anteriores,

al final disponemos de una metodología donde las fases se representan de forma
lineal, pero dentro de cada una de estas fases se pueden dar saltos hacia fases an-
teriores sin necesidad de esperar a que termine el ciclo completo. Por ejemplo, la
metodología incremental o la metodología en espiral.
Dato importante
Una metodología de desarrollo es un marco de trabajo que nos ofrece una serie de
herramientas para la gestión de un proyecto software en cada una de sus fases,
también llamado ciclo de vida.
256
26.3. Metodología lineal

Dentro de las metodologías lineales, la más conocida y usada es la metodología en casca-
da. Ésta ordena de forma rigurosa todas las fases del desarrollo software. En esta metodo-
logía, se ha de esperar forzosamente a la finalización de la fase anterior antes de empezar
con la nueva fase. Los principios básicos de esta metodología son:
• El proyecto se divide en fases secuenciales.
• Es muy importante la planificación (horarios, fechas, presupuesto, etc.).
• Existe un riguroso control durante toda la vida del proyecto software a través de
la documentación que se revisa por todas las partes implicadas a la finalización de
cada una de las fases.
Pese a que se pueden encontrar varios modelos de fases en esta metodología, en función
de que se añadan o eliminen fases, las fases más comunes implicadas son:
• Ingeniería y análisis de sistemas. A causa de que el software que se va a realizar la

gran mayoría de veces va a formar parte de un sistema más grande, el trabajo ha
de empezar estableciendo los requisitos de todos los elementos que lo conforman
y las interacciones que nuestro nuevo software tendrá con ellos.
• Análisis de requerimientos. Este proceso se centra en la recopilación de los requisi-

tos necesarios. Aglutina y estudia las necesidades de nuestros usuarios para deter-
minar los objetivos que se han de cubrir. En esta fase, tenemos que tener definido
el documento de especificaciones requeridas (SRD) donde se encuentran las espe-
cificaciones completas de lo que ha de realizar nuestro software. Este documento,
pese a que ha de ser concienzudo, no ha de entrar ni perderse en detalles internos.
• Diseño. Esta fase se enfoca en la definición de cuatro aspectos distintos del soft-
ware. El modelo de datos, la arquitectura que dará soporte a nuestro software, el de-
talle procedimental y la interfaz si este dispone de ella. De esta fase, se ha de salir
con el documento de diseño de software (DDS), que ha de contener la definición de
los aspectos anteriores y cómo éstos se interrelacionan. Es interesante hacer una
distinción entre el diseño de alto nivel o de arquitectura y el diseño detallado. El
diseño arquitectónico se realiza con el objetivo de definir la estructura de nuestro
software, mientras que el diseño detallado entra en la descripción de los algorit-
mos utilizados en nuestra solución.
• Diseño del programa. Es la fase en la que se crean lo algoritmos necesarios para

nuestro software y se realiza la selección del entorno de trabajo bajo el cual se rea-
lizará la codificación.
257
• Codificación. Esta es la fase donde se plasma todo lo anterior sobre el lenguaje

elegido. Para ello, se pueden utilizar diferentes organizaciones de código, como
librerías. También se tiende a realizar ensayos para corregir los posibles errores
cometidos en esta fase.
• Pruebas. En esta fase, las diferentes partes de nuestro software son ensambladas
para formar el sistema completo y se realizan las pruebas pertinentes para compro-
bar que cumplen con las especificaciones iniciales.
• Mantenimiento. Esta fase es muy importante ya que lo que no se haya hecho bien
en las fases anteriores, impactará en cuanto a que recursos tendremos que destinar
en esta fase. En muchas ocasiones, el software no está a la altura de lo requerido,
por mal entendimiento con el usuario o porque no cumpla con sus expectativas,
entonces volvemos hacia atrás (a la fase que toque) e intentamos corregir la des-
viación.
Pese a que de forma natural se vería como la mejor forma de desarrollar software, esto
depende en gran medida de la solución a crear. Las desventajas de esta metodología son:
• Los proyectos reales rara vez siguen este flujo secuencial que se propone en el mo-
delo y, por norma general, existen interacciones que van en contra de este modelo.
• Por norma, un usuario no es capaz de establecer todos los requisitos de los que pre-
cisa en un primer momento. El ciclo de vida de este modelo lo exige y no da opción
a volver atrás hasta haber llegado a la fase de mantenimiento. Llegado ese punto,
un posible cambio de diseño a principio del modelo puede tener consecuencias
enormes conforme vaya avanzando el nuevo cambio en las distintas fases.
• Otro inconveniente es que el usuario no verá nada hasta haber finalizado por com-
pleto todas las fases del modelo, lo que dificulta enormemente el feedback del
usuario. Esto puede desembocar en situaciones como algún fallo de diseño por
mala toma de especificaciones, que se acaba traduciendo en algo totalmente dife-
rente a lo que el usuario esperaba.
La mayor ventaja de este método radica en su sencillez y que es muy intuitivo a la hora de
emprender cualquier proyecto de desarrollo software.
258
26.4. Metodología iterativa

En este grupo de metodologías, podemos encontrar varios modelos. Vamos a explicar una
de ellas para que podamos ver cuáles son las particularidades que las diferencian de las
lineales.
Para ello, usaremos de guía la metodología de prototipos. Esta metodología, como su

nombre indica, se enfoca a la consecución de prototipos para entrar en un ciclo de revi-
sión que permite reducir alguno de los problemas que teníamos en otras metodologías
de tipo lineal.
Los prototipos son desarrollos incrementales que, poco a poco, se irán correspondiendo
con el aplicativo final. En esta metodología, se hace un gran esfuerzo en involucrar al
usuario en un par de fases fundamentales del modelo, la definición del problema que se
quiere atacar y en la fase de pruebas.
De esta forma, la metodología se asegura que los prototipos que se van realizando se
corresponden con las definiciones especificadas por el usuario y gestiona mucho mejor
la incertidumbre.
Se puede ver de forma sencilla que al final lo que se busca es mayor implicación del
usuario en el desarrollo de software y mejora en la interacción de los desarrollados con el
usuario a la hora de llevar a cabo sus especificaciones.
Esta metodología se compone de las siguientes fases:
• Una investigación inicial. En esta fase, se busca acotar el problema y el ámbito.

Identificar de forma general las soluciones necesarias para ver si es factible su
resolución mediante un proyecto software.
• Definición de requerimientos. En esta etapa, se recogen todos los requerimientos

de los usuarios. También es interesante añadir en esta fase los deseos de los usua-
rios en cuanto al proyecto, porque siempre nos pueden valer de pistas a la hora de
entender que es lo que el usuario quiere realmente. Como es normal, esta etapa es
de las más importantes en todo el ciclo de vida.
259
Es en esta fase donde el equipo determina requisitos a través de la construcción de

los prototipos, demos y retroalimentación del feedback del usuario sobre el proto-
tipo. En ella, podemos encontrar las siguientes subfases:
• Análisis y especificación. Se trata realizar un diseño básico para el prototipo ini-

cial con la información recogida en la toma de requerimientos.
• Diseño y construcción. Una vez hecho el análisis inicial, realizamos un diseño y

creamos el prototipo inicial, intentando tener el máximo posible de funcionali-
dades y con la interfaz de usuario lo más completa posible.
• Evaluación del prototipo. En esta fase, se le presenta a los usuarios el prototipo

creado para que éstos puedan comprobar si concuerda con sus peticiones, para
detectar posibles errores o por si surgen requerimientos adicionales durante las
pruebas. En este caso, se pasaría a la fase de modificación, sino se finalizaría la
iteración y se pasaría a la fase de diseño técnico.
• Modificación. En esta fase, es donde el equipo de desarrollo corregiría los erro-

res encontrados durante la fase anterior. También implementaría las posibles
mejoras observadas durante la fase anterior. Una vez finalizada esta fase, se pa-
saría de nuevo a la fase anterior, iniciando de nuevo el ciclo.
• Diseño técnico. Durante la construcción del prototipo, el equipo no ha realizado

un diseño detallado ni documentado a causa que el énfasis de las tareas ha estado
enfocado a la consecución de prototipos lo antes posible. Es en esta fase donde ese
diseño se perfila y se crea la documentación necesaria que ayudará en un futuro al
mantenimiento del desarrollo.
• Programación. En esta fase, finalmente se consolida el prototipo, intentando ase-

gurar que se cumplen todos los requerimientos del usuario.
• Operación y mantenimiento. Es la fase final del modelo. En esta fase, el nuevo

software pasa a producción. Gracias al ciclo de evaluación y modificación, se ase-
gura que el nuevo desarrollo cumple con las especificaciones y necesitará menos
mantenimiento.
Las ventajas de este modelo son claras, al poder presentar prototipos funcionales decrece
la incertidumbre del usuario y éste es más participativo, lo que implica que finalmente
el software tiene más posibilidades de cumplir con todas las especificaciones de forma
correcta.
260
También tiene inconvenientes, como el riesgo que, al entrar en una fase de iteración don-
de el usuario puede pedir mejoras, éste no pare y alargue de forma excesiva el desarrollo.
Se ha de intentar delimitar el ámbito del desarrollo para evitar esta situación.
26.5. Metodología lineal-iterativa

Podemos encontrar varias metodologías, pero explicaremos una de las más comunes para
dar una idea de cómo funciona este tipo.
Dentro de las metodologías lineal-iterativas podemos encontrar la metodología incre-

mental que se comporta de forma similar a un modelo en cascada, pero con la diferencia
de que en cualquier fase podemos volver hacia la fase inicial o que, una vez llegada a la
última fase, se puede volver a cualquiera de las fases anteriores.
Como ventaja diremos que es dinámica y flexible, permite usar las salidas de las fases
precedentes como entradas en las fases sucesivas y facilita enormemente la mejora o la
corrección de los errores detectados. Es de fácil aplicación e intuitiva, puesto que se basa
en otra metodología de fácil aplicación como es la cascada. Por el contrario, adolece de
una excesiva burocracia, como también le pasa al modelo en cascada.
26.6. Ejemplo
Una vez conocemos los tipos de metodologías que existen y cómo funcionan, vamos a ver
otros ejemplos de metodologías que nos podemos encontrar en el mercado.
Métrica v3 es una metodología promovida por el ministerio de Administraciones Públi-

cas, cuyo fin es:
• Definir un marco de desarrollo que ayude a conseguir los fines de la organización.
• Dotar a la organización de las aplicaciones necesarias, dando mucha importancia

al análisis de requisitos.
• Mejorar la productividad, permitiendo ser más flexibles a los cambios y reutilizan-

do código.
• Aumentar la fluidez en la comunicación entre los actores que participan el ciclo de

vida de una aplicación.
• Facilitar el mantenimiento de las aplicaciones.
261
Esta metodología define todos los procesos que intervienen en el desarrollo de sistemas
de información y los describe con detalle. Éstos están estructurados de la siguiente ma-
nera:
• Planificación de sistemas de la información.
• Desarrollo de sistemas de la información.
• Estudio de viabilidad del sistema.
• Análisis del sistema de información.
• Diseño del sistema de información.
• Construcción del sistema de información.
• Implantación del sistema de información.
• Mantenimiento del sistema de información.

• Tipos de metodologías tradicionales:
• Lineal: cascada, ciclo de vida secuencial sin opción a revisión en ninguna de las
fases.
• Iterativa: prototípica, ciclo de vida con iteraciones para la resolución de errores

en las fases previas.
• Lineal-iterativa: incremental, modelo hibrido con la posibilidad de revisión en

todas las fases.
• Ejemplos de metodologías: métrica v3, metodología promovida por el Ministerio

de Administraciones Públicas.
262
27. Metodologías de desarrollo ágil:

Scrum
“K. Schwaber indica que Scrum no es una metodología, sino un mar-
co de trabajo. Eso quiere decir que Scrum no te va a decir exacta-
mente lo que debes hacer. Así, en este proceso es muy importante
la creatividad, puesto que las personas implicadas no son un engra-
naje más de la máquina, sino que son el combustible necesario para
que todo se mueva.”
27.1. Metodologías ágiles

Las metodologías ágiles son métodos de ingeniería software que están fundamentados en
el desarrollo incremental e iterativo; donde las soluciones evolucionan a través del trabajo
de grupos multidisciplinares que se organizan ellos mismos.
En marzo de 2001, K. Beck, reunió a diferentes críticos de los modelos de mejora basados
en procesos. En la reunión, se acuñó el término de métodos ágiles para definir métodos
que estaban surgiendo como alternativas a las metodologías tradicionales, consideradas
excesivamente pesadas e inflexibles a causa de su burocracia y planificación excesiva. De
esta reunión, surgió el Manifiesto ágil, formado por los siguientes principios:
• Los individuos y su interacción deberá estar por encima de los procesos y las he-
rramientas.
• El software que funciona deberá estar por encima de la documentación exhaustiva.
• La colaboración con el cliente deberá estar por encima de la negociación contrac-

tual.
• La respuesta al cambio deberá estar por encima del seguimiento de un plan.
El principio más importante de todos es que tienen más importancia los individuos y su
interacción que los procesos y las herramientas. Las herramientas ayudan a mejorar la
eficiencia pero los trabajos que requieren conocimiento implícito sin personas con cono-
cimiento técnico y la actitud adecuada no producen resultados.
263
Durante la época de la reingeniería, las empresas tipo consultoras gritaron a los cuatro
vientos que gracias a la organización y a los procesos se podían conseguir grandes resul-
tados con personas mediocres. Este principio es altamente peligroso, sobre todo cuando
el trabajo necesita de grandes dosis de creatividad e innovación.
Es más importante un software funcionando que una documentación exhaustiva. Esto,

pese a parecer algo obvio, no lo es tanto una vez se lleva a la realidad. En las empresas,
se pueden encontrar documentaciones perfectamente realizadas y con niveles de detalle
extraordinario de proyectos que básicamente han quedado para no ser usados porque
al final el producto no era lo que se esperaba o porque simplemente sobre el papel se
soporta pero resulta imposible llevarse a la realidad. La documentación es necesaria para
la transferencia de conocimiento o para que exista un histórico de lo que se ha realizado,
pero antes está el producto último de todo el proyecto, que es el software. Por eso, la docu-
mentación ha de ser reducida a la mínima expresión, porque al final no aporta valor al de-
sarrollo. Además, el exceso de documentación se convierte en la forma de comunicación
entre los departamentos, creando muros y haciendo que el contacto personal se diluya.
Es más importante la colaboración con el cliente que la negociación contractual. Las

metodologías ágiles están especialmente indicadas para aquellos proyectos donde las
especificaciones son difíciles de definir inicialmente o que durante el ciclo de vida son
cambiantes. En el desarrollo ágil, se intenta ofrecer un producto rápido y los ciclos de
interacción se realizan sobre éste para ir creciendo hacia la solución final. Es muy impor-
tante que el cliente esté inmerso en el proceso y que no se limite a reuniones donde dé sus
especificaciones y se quede esperando a que el producto llegue.
Es más importante la respuesta al cambio que el seguimiento de un plan. Teniendo en

cuenta que, en la actualidad, el entorno pocas veces se mantiene constante el tiempo
suficiente como para poder cumplir un plan de desarrollo a rajatabla, las nuevas metodo-
logías se han de adaptar para que los cambios no sean un problema. Para ello, las metodo-
logías ágiles se establecen en ciclos cortos de desarrollo que permiten cambios de rumbo
e incluso desechar lo realizado, ya que no supone meses de trabajo.
Entre las diferentes metodologías ágiles, podemos encontrar:
• Adaptive Software Development.
• Scrum.
• Win Win Spiral.
• Extreme Programming.
264
• XBreed.
• Pragmatic programming.
• Lean develomepent.
• Internet Speed Development.
• Ágile Modeling.
• Ágile Model Drive Development.
• Ágile Unified Process.
• Crystal Methods.
27.2. Scrum
En palabras de K. Schwaber, creador de Scrum:
“Scrum no es una metodología, es un marco de trabajo. Eso quiere decir que Scrum no te va
a decir exactamente lo que debes hacer”.
Las palabras de K. Schwaber pueden ser desalentadoras de entrada para aquéllos que
durante mucho tiempo han estado acostumbrados a trabajar con metodologías tradicio-
nales, puesto que éstas organizaban cada uno de los pasos del proceso y prácticamente no
dejaban cabida a la improvisación.
En este proceso es muy importante la creatividad, puesto que las personas implicadas
no son un engranaje más de la máquina, sino que son el combustible necesario para que
todo se mueva.
27.2.1. El funcionamiento de Scrum

Se empieza con la visión global del producto y se especifica, dando detalles de las fun-
cionalidades o módulos más importante que pueden desarrollarse en ciclos de tiempo
breves. Estos ciclos son denominados sprints y pueden durar semanas. Puesto que la du-
ración de los sprints no es una ciencia exacta, se va adaptando en un proceso de revisión
continuo, según el proyecto y el equipo, hasta conseguir que estos sean óptimos. Cada
ciclo es una iteración que finaliza con un producto, que es la evolución del ciclo anterior.
265
Las iteraciones son la base del desarrollo ágil y Scrum gestiona su evolución a través de
reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el día ante-
rior y el proyectado para el día siguiente.
El control durante el proyecto se realiza con las prácticas de gestión ágil:
• Revisión de las iteraciones. Cuando se finaliza una iteración, se realiza una revi-
sión, reuniendo a todas las personas implicadas en el proyecto. Esta reunión es el
periodo máximo que se invierte en el proyecto para reconducir cualquier desvia-
ción.
• Desarrollo incremental. Durante el proyecto, los implicados no trabajan con dise-

ños o abstracciones. El desarrollo incremental implica que al final de cada itera-
ción se disponga de una parte del software totalmente operativa, que pueda ser
comprobada y verificada.
• Desarrollo evolutivo. En Scrum, se toma la inestabilidad que puede existir en el

entorno como una condición de trabajo más y se adaptan técnicas de trabajo que
permitan adaptabilidad sin perjudicar a la calidad del software que se generará en
cada iteración.
• Autoorganización. En Scrum, los equipos son autoorganizados, no autodirigidos

como en otras metodologías. Las personas tienen margen suficiente como para
tomar las decisiones oportunas.
• Colaboración. Las prácticas que se siguen en un entorno de trabajo ágil facilitan

enormemente la colaboración en el equipo. Es necesario para que funcione la au-
toorganización como herramienta de control. Cada miembro integrante del equipo
ha de colaborar de forma abierta con el resto, según sus capacidades y conocimien-
tos, y no según una jerarquía establecida.
Como se puede extrapolar de las prácticas de gestión, las personas son lo más importante
y el sprint la base sobre la que se sustenta la metodología.
Los artefactos que conforman el desarrollo con la metodología Scrum son:
• Las reuniones. Hay tres tipos de reuniones en función del momento del sprint:
• Planificación inicial del sprint. Se han de planificar los sprints; en cada jornada
de trabajo previo al inicio de un sprint, se ha de determinar cuál será el trabajo
que se ha de realizar y los objetivos que se han de cumplir.
266
• Reunión diaria de trabajo. Cada día, se realiza una breve reunión (breve, porque
el objetivo es dar a conocer el trabajo hecho hasta la fecha y las previsiones). Es-
tas reuniones no son para entrar en temas profundos que nos consuma excesivo
tiempo en divagaciones que no aporten valor al proceso.
• Revisión del sprint. Se realiza al final. En ella, se analiza el incremento generado

durante ese sprint.
• Los elementos:
• Historia. Cada uno de los requisitos del usuario.
• Pila del producto. Lista de historias definidas por el usuario. Inicialmente, en

esta lista se añaden todas las peticiones que los usuarios realizan. Dada la natu-
raleza flexible del modelo, esta pila muta durante el ciclo de creación. Hay que
destacar que la pila ha de estar perfectamente lista antes de la reunión de plani-
ficación del sprint. Es fácil caer en el error de pensar que ésta ha de contener his-
torias perfectamente definidas, con estimaciones correctas y que las prioridades
de cada historia tengan que estar perfectamente definidas; realmente, esto no es
así. Nos tenemos que asegurar de lo siguiente:
• La pila de producto debe existir. Esto parece obvio, pero en el mundo de soft-
ware estas cosas pasan.
• Ha de haber una pila de producto y un dueño de producto.
• Los elementos importantes han de tener ratios de importancia asignadas. De

esta forma, los elementos importantes están al principio de la lista. El tema de
las prioridades no es muy importante, da igual que todos los elementos menos
prioritarios tengan la misma prioridad, la cuestión es que los más importantes
destaquen.
• El dueño del producto ha de comprender cada historia.
• Pila de sprint. Lista de trabajos a realizar durante un sprint y la creación de un

nuevo prototipo del aplicativo.
• Incremento. Conjunto de mejoras que se ha realizado teniendo como punto de

partida el proyecto generado en el sprint anterior y el generado en el último
sprint.
267
• Roles. En Scrum, se clasifican todas las personas que intervienen o tienen interés
en el desarrollo del proyecto en cuatro categorías:
• Propietario del producto (product owner):
• Representa a todos los interesados en el producto final.
• Marca las prioridades del producto.
• Lleva el control de las estimaciones.
• Controla el retorno de la inversión (ROI).
• Equipo (Scrum team):
• Transforma las historias del sprint en un incremento de funcionalidades en el

software.
• Desarrolla el producto con calidad.
• Autogestionado y autoorganizado.
• Es multifuncional: teniendo en cuenta que es muy importante el equipo y pue-

de tomar decisiones, la gente que lo conforma ha de tener conocimiento en
varias ramas y no ser especialista en una única disciplina.
• Se recomienda que no sea de más de ocho integrantes: como en el caso de

la duración de los sprints, la experimentación es importante, puesto que hay
factores como las relaciones interpersonales que pueden afectar. Puede que
en un proyecto funcionen perfectamente ocho personas y en otro cuatro, hay
que adaptarse.
• Gestor de Scrum. (Scrum manager o Scrum master):
• Responsable del proceso de Scrum.
• Encargado de incorporar Scrum a la cultura de la organización. Es importante

que esta cultura no se quede en el equipo, sino que sea parte del ADN del
cliente, puesto que éste ha de estar inmerso en el proceso para que todo fun-
cione.
268
• Asegurar el cumplimiento de los roles y responsabilidades.
• Formación y entrenamiento en el proceso. El Scrum master se ha de respon-

sabilizar de su equipo, de cómo está anímicamente, y se ha de encargar del
entorno para evitar cualquier interferencia en él. También se ha de ocupar de
la formación, si fuera necesaria, de los integrantes del equipo.
Por último, haremos una referencia a una historia bastante utilizada a la hora de explicar
el Scrum:
“Una gallina y un cerdo paseaban por la carretera. La gallina dijo al cerdo: ‘¿Quieres abrir
un restaurante conmigo?’. El cerdo consideró la propuesta y respondió: ‘Sí, me gustaría. ¿Y
qué venderíamos?’. La gallina respondió: ‘Huevos con jamón’.
El cerdo se detuvo, hizo una pausa y contestó: ‘Pensándolo mejor, creo que no voy a abrir un
restaurante contigo’. La gallina lo cuestionó por la razón de su negativa, a lo que el cerdo
le contesto: ‘En este negocio, yo estaría realmente comprometido, mientras que tu estarías
sólo implicada’”.
Scrum hace una clara diferencia entro los dos grupos (gallinas y cerdos) para intentar
garantizar que quienes tengan la responsabilidad también tengan la autoridad necesaria
para lograr el éxito del proyecto, y que quienes no la tengan no puedan inmiscuirse y pro-
vocar interferencias que puedan afectar al proceso.

• Introducción: de dónde surgen las metodologías ágiles y cuáles son las motivacio-
nes para su uso.
• Metodologías ágiles: su nacimiento en 2001 y el fin que persiguen. Creación del

Manifiesto ágil.
• Scrum: metodología ágil de gran difusión en el mercado:
• Funcionamiento del Scrum:
• Desarrollo incremental.
• Autogestión.
• Colaboración.
269
• Artefactos que actúan en la metodología:
• Reuniones: tipo de reuniones que se realizan durante un proceso de desarrollo

usando esta metodología.
• Elementos necesarios en el proceso para el buen funcionamiento de los

sprints.
• Roles necesarios para el buen funcionamiento de la metodología. Se reparten

las responsabilidades y se relaciona en un proceso típico de desarrollo.
Dato importante
Las iteraciones son la base del desarrollo ágil y Scrum gestiona su evolución a tra-
vés de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado
el día anterior y el proyectado para el día siguiente.
270
28. CMMI
“El CMMI nace de la necesidad de establecer unas mejores prác-
ticas que ayuden a la organización a gestionar los departamentos
de desarrollo. ”
28.1. Introducción al concepto de CMMI

El CMMI (Capability Maturity Model Integration) es un marco de trabajo de referencia
para las organizaciones que se puede emplear en la mejora de los procesos de desarrollo,
adquisición y mantenimiento de productos y servicios.
Este modelo propone una serie de mejoras prácticas que las organizaciones pueden se-
guir para implantar procesos productivos más efectivos. A esto se le denomina modelos
de madurez porque proponen que la adopción de las prácticas se realice de forma gradual.
Estas mejores prácticas se publican en los documentos modelos. En la actualidad, cubren

tres áreas de interés: desarrollo, adquisición y servicios. CMMI en la actualidad se en-
cuentra en la versión 1.3, la cual corresponde a CMMI-SVC, liberada el 1 de noviembre de
2010. Dentro, podemos encontrar tres constelaciones de la versión 1.2:
• CMMI para desarrollo (CMMI-DEV o CMMI for development), versión 1.2. Trata
los procesos de desarrollo, tanto de productos como de servicios. Dentro de esta
constelación, existen dos modelos diferentes.
• CMMI-DEV.
• CMMI-DEV + IPPD.
• CMMI para la adquisición (CMMI-ACQ o CMMI for adquisition), versión 1.2. Trata
la gestión de la cadena de suministros, adquisición y contratación externa den los
procesos de gobierno.
• CMMI para servicio (CMMI-SVC o CMMI for services). Trata todas las actividades
que requieren gestionar, establecer y prestar servicios.
271
Sin tener en cuenta la constelación o modelo por la que se decida una organización, las
prácticas CMMI se deben adaptar a la organización en función de sus objetivos de nego-
cio.
Una organización no puede ser certificada CMMI, sino que es evaluada usando un méto-
do como SCAMPI. La evaluación SCAMPI establece el nivel (1-5) de madurez o capacidad
que ha alcanzado una organización que sigue las prácticas CMMI en sus procesos. El
objetivo principal es comparar los procesos actuales con los de referencia del modelo y
establecer las fortalezas junto con las posibles áreas de mejora. En la actualidad, existen
tres clases de evaluación:
• SCAMPI clase A. El método más amplio, con mayor cobertura del modelo y el úni-
co que puede proporcionar un nivel de madurez o perfil de capacidad. Es liderado
por un SCAMPI Lead Appraiser autorizado por el SEI.
• SCAMPI clase B. Es menos amplio y detallado que el clase A y más económico. Se

utiliza como evaluación inicial o parcial, enfocado en las áreas que requieren aten-
ción. En este caso, no requiere de un Lead Appraiser para ser realizado.
• SCAMPI clase C. Es el más sencillo, económico y requiere una capacitación menor.

Se enfoca en áreas de interés o de mayor riesgo en la organización.
CMMI tienes dos representaciones en función de los diferentes objetivos de mejora que
se proponga la organización:
• Por etapas (staged):
• Ofrece una secuencia para la mejora, donde cada una es base de la siguiente.
• Se puede migrar fácilmente del CMM al CMMI-SW.
• Continuo (continuous):
• Cada nivel de madurez es una plataforma bien definida para evolucionar la me-
jora.
• Existen cinco niveles de madurez.
• Cada nivel es una base para la mejora, utilizando una secuencia probada desde
sus bases.
272
Los niveles de madurez, en función de la representación escogida, son:
• Por etapas:
• Nivel 1 (inicial). El proceso es impredecible, reactivo y pobremente controlado.
• Nivel 2 (administrado). El proceso es reactivo y se caracteriza por su aplicación

a proyectos.
• Nivel 3 (definido). El proceso es proactivo y se ve a nivel de la organización.
• Nivel 4 (administrado cuantitativamente). El proceso es medido y controlado.
• Nivel 5 (optimizado). El proceso se enfoca en la mejora continua.
• Continuo:
• Nivel 0 (incompleto). El proceso no se ejecuta o se hace parcialmente.
• Nivel 1 (ejecutado). El proceso se ejecuta y se producen productos basados en

productos de entrada identificados.
• Nivel 2 (administrado). El proceso es reactivo y se caracteriza por su aplicación

a proyectos.
• Nivel 3 (definido). El proceso es proactivo y se ve a nivel de la organización.
• Nivel 4 (administrado cuantitativamente). El proceso es medido y controlado.
• Nivel 5 (optimizado). El proceso se enfoca en la mejora continua.
28.2. Arquitectura del modelo

En la representación por niveles del CMMI, cada uno contiene varias áreas de proceso,
éstas quedan definidas por uno o varios objetivos específicos y un objetivo genérico. Cada
uno de ellos está vinculado con un conjunto de prácticas, a las que llamamos específicas
o genéricas respectivamente.
28.2.1. Objetivos y prácticas genéricos

Los objetivos y prácticas genéricos tienen que ver con el grado de compromiso institucio-
nal de los procesos. Son llamados así porque son los mismos en todas las áreas de proceso
(aunque existen aspectos específicos para cada una de ellas). Cumplir con un objetivo
genérico de un área de proceso implica tener un mayor control de la planificación e im-
plementación de los procesos vinculados a esa área de proceso.
273
Por ejemplo, en el nivel 2, el objetivo (GG) y las prácticas genéricas (GP) son los siguien-
tes:
• GG 2. Institucionalizar un proceso administrado:
• GP 2.1. Establecer políticas organizacionales.
• GP 2.2. Planificar el proceso.
• GP 2.3. Proveer recursos.
• GP 2.4. Asignar responsabilidades.
• GP 2.5. Entrenar al personal.
• GP 2.6. Administrar la configuración.
En los niveles 3, 4 y 5, a los anteriores se agregan los siguientes:
• GG 3 Institucionalizar un proceso definido:
• GP 3.1. Establecer un proceso definido.
• GP 3.2. Recolectar información para mejoras.
28.2.2. Objetivos y prácticas específicos

Los objetivos y prácticas específicos están vinculados a un área de proceso determinada.
Son considerados elementos que deben ser satisfechos para implementar exitosamente
los procesos relacionados con un área de proceso en particular.
28.3. Áreas de procesos CMMI

Las áreas de procesos que encontramos en la actualidad dentro del modelo CMMI son:
• Risk Management (RSKM). Esta área es una evolución de las prácticas básicas
de manejo de riesgo incluidas en la Planificación del Proyecto (PP) y Monitoreo y
Control del Proyecto (PMC) que pertenecen al nivel 2. Se plantean las acciones a
tomar para anticipar y mitigar los riesgos que surgen en los proyectos y minimizar
su impacto sobre éstos.
• Integrated Teaming (IT) solo para IPPD. Únicamente aplicable cuando se em-
plea la disciplina IPPD. Su propósito es establecer y mantener equipos integrados
para el desarrollo de productos.
274
• Decision Analysis and Resolution (DAR). Tiene como fin que algunas decisiones
sean tomadas en función a una serie de procesos formales. Por ejemplo, la selec-
ción de un nuevo proveedor. Al final se trata de formalizar este tipo de cuestiones
dentro de la organización. Para ello, se tiene que:
• Establecer criterios (qué decisiones es recomendable que pasen por este proce-
so y cuáles no, cuáles son los criterios de evaluación, etc.).
• Identificar soluciones alternativas.
• Determinar métodos para evaluarlas.
• Evaluar las soluciones alternativas y seleccionar una de ellas.
• Organizational Environment for Integration (OEI). Tiene como propósito pro-

veer la infraestructura necesaria para que los distintos grupos implicados en el
proyecto trabajen de manera integrada. En general, la infraestructura mencionada
contendrá los siguientes elementos:
• Una definición de la visión de la organización, la que deberá hacer referencia a

valores y prácticas importantes para esta disciplina (trabajo en equipo, desarro-
llo de productos en forma concurrente, etc.).
• Un ambiente de trabajo preparado para la colaboración e integración del perso-

nal y de los distintos grupos involucrados.
• Personal especialmente entrenado para integrarse, colaborar y liderar a otros.
• Organizational Process Performance (OPP). Tiene como propósito comprender

cuál es el rendimiento de los procesos de la organización y emplear dicha informa-
ción para administrar cuantitativamente los proyectos.
En una organización, en este nivel, las métricas de los procesos (esfuerzo, efectivi-
dad del testing, etc.) y del producto (densidad de defectos, confiabilidad, etc.) son
empleadas para modelar la performance pasada y para predecir la futura. A su vez,
estos modelos son empleados como base para contrastar el desempeño real de los
proyectos.
Con esta información, la organización estará en condiciones de determinar qué

procesos son estables, cuáles merecen atención, cuáles deberían ser estadística-
mente controlados y cómo y cuáles deberían ser mejorados.
275
• Quantitative Project Management (QPM). Administra el proyecto para cumplir

con sus objetivos de calidad y desempeño. El proyecto es gestionado cuantitativa-
mente, lo cual implica:
• Establecer y mantener los objetivos de calidad y desempeño del proyecto.
• Configurar el proceso que empleará el proyecto, seleccionando aquellos subpro-

cesos sobre la base de su estabilidad y/o capacidad (lo que se encuentra en los
modelos y líneas base mencionados en el área de proceso anterior).
• Seleccionar los subprocesos del proceso del proyecto que serán estadísticamen-
te administrados, y las técnicas y herramientas.
• Monitorear el comportamiento del proyecto para determinar si se cumplen o no

los objetivos de calidad y desempeño.
• Monitorear el desempeño de los subprocesos seleccionados para determinar si

se pueden cumplir los objetivos de calidad y desempeño, y tomar acciones co-
rrectivas de ser necesario.
• Organizational Innovation and Deployment (OID). Selecciona e implanta cam-

bios que, de manera incremental, permitan mejorar los procesos y las tecnologías
empleadas por la organización, al mismo tiempo que se alinean los objetivos de
calidad y desempeño con los objetivos del negocio.
• Causal Analysis and Resolution (CAR). Identifica, analiza y elimina las causas, no
sólo de los defectos sino también de los problemas.
• Integrated Supplier Management (ISM) solo para SS. Identifica los potenciales
proveedores de productos y establece relaciones con ellos.
• Requirements Management (REQM). Mantiene bajo control los requerimientos

que el producto a desarrollar deberá satisfacer. Las prácticas incluidas aquí apun-
tan a que los requerimientos no solo estén claramente identificados, sino también
que todos los involucrados en el proyecto estén de acuerdo en su significado.
• Project Planning (PP). Establece y mantiene el plan que será empleado para eje-
cutar y monitorear el proyecto. El plan se desarrolla sobre la base de los reque-
rimientos administrados por el área REQM. Dentro de esta área de proceso, se
incluyen todas las actividades necesarias para determinar el alcance del proyecto,
estimar esfuerzo y costos, establecer la planificación, identificar riesgos y obtener
el compromiso de todos los involucrados respecto al plan de proyecto.
276
• Project Monitoring and Control (PMC). Monitorea la ejecución del proyecto, em-
pleando para ello el plan, y gestiona acciones correctivas en el caso de detectarse
desvíos.
• Supplier Agreement Management (SAM). Está pensada para todo lo relacionado

con la adquisición de productos que vayan a ser incorporados en la solución a
entregar al cliente.
• Measurement and Analysis (M&A). Desarrolla y mantiene las capacidades de me-

dición que permitan satisfacer las necesidades de información de la organización.
• Process and Product Quality Assurance (PPQA). Provee de una evaluación obje-
tiva de los procesos y de los artefactos producidos.
Es importante aclarar que las prácticas implican:
• Evaluar los procesos ejecutados, los artefactos producidos y los servicios provis-
tos contra los estándares y descripciones de proceso aplicables.
• Identificar no conformidades, comunicarlas a los responsables y asegurar su re-

solución.
• Informar a los interesados el resultado de las actividades de aseguramiento de

la calidad.
• Configuration Management (CM). Tiene como propósito mantener la integridad

de todos los artefactos producidos por el proyecto.
• Requirements Development (RD). Es la encargada de producir y analizar los re-

querimientos del cliente, del producto y de las componentes del producto.
• Technical Solution (TS). En el nivel 2 no era tan importante formalizar el diseño

y la construcción del producto. Una vez que la organización llega a este nivel, ne-
cesitaremos hacerlo.
277
• Product Integration (PI). El propósito de esta área de proceso es ensamblar el

producto a partir de sus componentes, garantizando que su funcionamiento sea
el previsto.
• Verification (VER). Tiene como objetivo garantizar que los artefactos selecciona-
dos cumplan con los requerimientos asignados. Similar en ciertos aspectos a va-
lidación, esta área de proceso apunta a evaluar si el producto final y los productos
intermedios del proyecto cumplen con los requerimientos del cliente, del producto
y de las componentes del producto.
• Validation (VAL). Esta área está enfocada en demostrar si el producto satisface las
necesidades de uso en el ambiente deseado.
• Organization Process Focus (OPF). Una organización de nivel 3 debe tener un

enfoque formal y disciplinado para continuamente mejorar sus procesos. El propó-
sito de esta área en particular es planificar e implementar las mejoras a los proce-
sos de la organización.
• Organization Process Definition (OPD). Esta área de proceso, complementaria

de la anterior, establece y mantiene un conjunto utilizable de activos de proceso.
En este contexto, un activo es cualquier elemento que forme parte de los procesos
de la organización (una política, la descripción de un proceso, un estándar, la plan-
tilla de un documento, etc.) y que sea use para describir, implementar y mejorar
procesos.
• Organizational Training (OT). Esta área provee de los conocimientos y habilida-

des necesarios para que el personal pueda realizar sus tareas de forma eficiente y
facilitar de esta forma el cumplimiento de los objetivos estratégicos de la organi-
zación.
• Integrated Project Management for IPPD (IPPD). Sobre las prácticas del nivel
anterior, su fin es el de gestionar el proyecto y la implicación de los interesados
a través de un proceso que ha sido adaptado a las necesidades particulares del
proyecto.
278
28.4. Niveles CMMI

En función de la representación escogida para aplicar CMMI, las áreas de procesos que
han de estar operativas en cada nivel son:
• Por etapas:
• Nivel 2 (administrado):
• Requirements Management (REQM).
• Project Planning (PP).
• Project Monitoring and Control (PMC).
• Supplier Agreement Management (SAM).
• Measurement and Analysis (M&A).
• Process and Product Quality Assurance (PPQA).
• Configuration Management (CM).
• Nivel 3 (definido):
• Requirements Development (RD).
• Technical Solution (TS).
• Product Integration (PI).
• Verification (VER).
• Validation (VAL).
• Organization Process Focus (OPF).
• Organization Process Definition (OPD).
• Organizational Training (OT).
• Integrated Project Management for IPPD (IPPD).
• Risk Management (RSKM).
• Integrated Teaming (IT).
279
• Decision Analysis and Resolution (DAR).
• Organizational Environment for Integration (OEI).
• Nivel 4 (administrado cuantitativamente):
• Organizational Process Performance (OPP).
• Quantitative Project Management (QPM).
• Nivel 5 (optimizando):
• Organizational Innovation and Deployment (OID).
• Causal Analysis and Resolution (CAR).
• Continuo:
• Administración de procesos:
• Organization Process Focus (OPF).
• Organization Process Definition (OPD).
• Organizational Training (OT).
• Organizational Process Performance (OPP).
• Organizational Innovation and Deployment (OID).
• Administración de proyectos:
• Project Planning (PP).
• Project Monitoring and Control (PMC).
• Supplier Agreement Management (SAM).
• Integrated Project Management for IPPD (IPPD).
• Risk Management (RSKM).
• Integrated Teaming (IT).
• Integrated Supplier Management (IPM).
• Quantitative Project Management (QPM).
280
• Ingeniería:
• Requirements Management (REQM).
• Requirements Development (RD).
• Technical Solution (TS).
• Product Integration (PI).
• Verification (VER).
• Validation (VAL).
• Soporte:
• Measurement and Analysis (M&A).
• Process and Product Quality Assurance (PPQA).
• Configuration Management (CM).
• Organizational Environment for Integration (OEI).
• Decision Analysis and Resolution (DAR).
• Causal Analysis and Resolution (CAR).
Las ventajas de la representación continua son:
• Se centra en los problemas, mitigación de riesgos y en lo interesante para los ob-

jetivos de la organización.
• Permite la comparación entre áreas de proceso.
• Permite una comparación contra el modelo.
Las ventajas de la representación por etapas son:
• Provee una secuencia de las mejoras desde la administración básica hasta niveles
de alta madurez.
• Permite la comparación entre organizaciones, por los niveles de madurez.
• Provee un solo indicador que permite la comparación entre organizaciones.
281

• Introducción: necesidad de establecer unas mejores prácticas que ayuden a la or-

ganización a gestionar los departamentos de desarrollo. Establecimiento de ma-
durez de las organizaciones en función del establecimiento de áreas de procesos.
• Arquitectura del modelo:
• Objetivos y prácticas genéricas para todas las áreas de procesos.
• Objetivos y prácticas especificas para las áreas de procesos.
• Áreas de procesos:
Divisiones funcionales de la organización por niveles de madurez.
• Niveles CMMI:
• Continuo: con cincos niveles de madurez, que indican en qué momento se en-
cuentra la organización.
• Por etapas: aplicando el foco sobre cada tipología de área de proceso.
Dato importante
En la representación por niveles del CMMI, cada uno contiene varias áreas de pro-
ceso, éstas quedan definidas por uno o varios objetivos específicos y un objetivo
genérico. Cada uno de ellos está vinculado con un conjunto de prácticas, a las que
llamamos específicas o genéricas respectivamente.
282
29. Caso práctico: desarrollo de un

novedoso sistema tecnológico
“A la hora de emprender un proyecto de desarrollo, nos encontra-
mos con que se ha de decidir cuál será la arquitectura de dicho pro-
yecto, y asaltan multitud de dudas, ¿qué lenguaje usaremos?, ¿cuál
será el entorno de desarrollo?, ¿usaremos algún tipo de metodolo-
gía? y, si es así, ¿cuál?”
29.1. Caso práctico

Se plantea la siguiente cuestión: Startup tecnológica que quiere desarrollar un novedoso
sistema de indexación de fuentes y comercializar su uso a través de un modelo SOA. El
equipo inicial será:
• Diez personas dedicadas al desarrollo de dicha solución.
• Una persona encargada de los sistemas.
• Un diseñador web.
• Un administrativo.
• Más adelante se incorporará un comercial que se encargará del área de ventas.
Facturación esperada en torno a los 100.000 €, se asume que la facturación el primer año
no será muy elevada a causa de la necesidad de la creación del software.
29.1.1. Infraestructura de aplicaciones

Puesto que es una startup y los medios son algo limitados, normalmente se priorizará
buscar una solución Open Source y evitar el pago de licencias innecesarias. Como estra-
tegia de ahorro, todos los servidores estarán alojados en un entorno IaaS. Usaremos como
proveedor Amazon web services. Seleccionaremos, a la hora de contratar los servicios,
que nuestras instancias estén en su centro de Irlanda para prevenir posibles problemas
de LOPD.
283
29.1.1.1. Solución
Dada la prioridad principal de ahorro de costes en la selección y el entorno que se quiere
montar para la gente de TI, usaremos alguna distribución de Linux del tipo Debian o
Ubuntu que tienen ya un bagaje y una importante comunidad que da soporte. Para aqué-
llos con perfiles poco técnicos, les dotaremos de máquinas con Windows 7 que actual-
mente está dando buenos resultados y tiene buenas críticas, al contrario que su antecesor
Windows Vista.
29.1.1.2. Desarrollo
Para la creación, se ha optado por la solución usar J2EE.
Como IDE de desarrollo se optará por Elipse en su última rama estable. Eclipse es un
reputado entorno de desarrollo creado por IBM que se ha convertido en un referente en el
mundo del desarrollo, al igual que otros entornos como NetBeans.
Como control de versiones, se usará Git sobre una máquina Linux. Git es uno de los con-
troles de versiones más usado actualmente en el mundo Open Source, porque es robusto
y fiable y cubre por completo todas las necesidades del equipo de desarrollo.
Como gestor de seguimiento de errores, usaremos Bugzilla. Pese a que hay muchos en el
mercado, éste Open Source está desarrollado y soportado por Mozilla.
Puesto que el desarrollo se realizará usando Scrum, se implantará como herramienta Agi-
lo for Scrum, una herramienta gratuita ya consolidada y utilizada por algunas grandes
multinacionales.
Como servidor de aplicaciones, usaremos TomCat, que se adapta perfectamente a la filo-

sofía de la empresa, es gratis, fácil de manejar y se puede montar en cualquier entorno, ya
sea Windows o Linux (en nuestro caso será instancias de máquinas Linux).
29.1.1.3. Diseño
Como editor gráfico, se usará GIMP, una alternativa gratuita que lleva tiempo en el mer-
cado y ofrece resultados de calidad.
Como editor web, se usará BlueFish, un editor gratuito que pese a estar lejos de otras he-
rramientas más profesionales de pago tiene las funcionalidades necesarias para el desa-
rrollo de nuestra web corporativa y para realizar el maquillaje necesario de los desarrollos.
284
29.1.1.4. Correo electrónico

Para reducir costes, la opción elegida es tener un servicio de correo en la nube. De las
diferentes opciones, se ha elegido Gmail, que no sólo tiene una disponibilidad del 99.9%
sino que además tiene un precio bastante competitivo, ofreciendo Google Apps por 4€
(aproximadamente 6$) por usuario al mes, frente a 27$ por usuario al mes que se cobra
Office365por la suit completa.
29.1.1.5. Ofimática
Como consecuencia de la elección de Google Apps, tenemos disponibles prácticamente
todos los aplicativos típicos de un entorno ofimático, procesador de texto, hoja de cálculo
y creación de presentaciones. También como posibilidad y dado que no ofrece ningún
problema con Google Apps, instalaremos en las máquinas OpenOffice.org. Éste se puede
instalar en cualquier máquina con sistema operativo Windows o Linux y nos ofrece una
completa suit ofimática con un entorno muy amigable y fácil de usar.
29.1.1.6. Software de gestión unificada de empresa

Dado que es una empresa pequeña, inicialmente se externalizarán los temas de contra-
tación, gestión de nóminas y otros temas más puramente relacionados con el área de
finanzas o RRHH.
29.1.1.7. Comunicaciones
Para ahorrar también en las comunicaciones, se contratará con alguna empresa una so-
lución basada en Asterisk, mediante un siptrunk. De esta forma, dispondremos de una
infraestructura voip que nos permitirá no sólo tener salas de reuniones virtuales, sino que
comunicación entre nosotros y el exterior desde cualquier sitio en el que dispongamos de
una conexión a internet. Asterisk es un reputado software que actualmente está creciendo
gracias a la comunidad que tiene detrás dando soporte y que, con un buen servicio, puede
crear entornos complejos. Antes sólo estaban disponibles soluciones como Avaya o Nor-
tel, de costes muy elevados.
29.1.1.8. Conclusiones
El Open Source ha revolucionado el entorno de la empresa, permitiéndonos montar una
arquitectura de sistemas completa casi sin más inversión que la del conocimiento que
podemos buscar fuera mediante contratación o externalización.
285
29.2. Resumen de aplicaciones
29.2.1. Amazon web services

En este caso, usaremos el Amazon Elastic Compute Cloud (Amazon EC2).
“Amazon Elastic Compute Cloud (Amazon EC2) es un servicio web que proporciona capa-
cidad informática con tamaño modificable en la nube. Está diseñado para facilitar a los
desarrolladores recursos informáticos escalables y basados en web.
La sencilla interfaz de servicios web de Amazon EC2 permite obtener y configurar su ca-
pacidad con una fricción mínima. Proporciona un control completo sobre sus recursos in-
formáticos y permite ejecutarse en el entorno informático acreditado de Amazon. Amazon
EC2 reduce el tiempo necesario para obtener y arrancar nuevas instancias de servidor en
minutos, lo que permite escalar rápidamente la capacidad, ya sea aumentándola o redu-
ciéndola, según cambien sus necesidades. Amazon EC2 cambia el modelo económico de la
informática, al permitir pagar sólo por la capacidad que utiliza realmente. Amazon EC2
proporciona a los desarrolladores las herramientas necesarias para crear aplicaciones re-
sistentes a errores y para aislarse de los casos de error más comunes.”
Amazon EC2
29.2.2. Debian
“Debian es un sistema operativo gratuito, una de las distribuciones de Linux más popu-
lares e influyentes. Es conocido por su adhesión a las filosofías del software libre y por su
abundancia de opciones (su actual versión incluye más de 18 mil paquetes de software,
para 11 arquitecturas de computadora). Debian GNU/Linux, también es base para otras
múltiples distribuciones de Linux, como Knoppix, Linspire, MEPIS, Xandros y la familia
Ubuntu. También es conocido por su sistema de gestión de paquetes (especialmente, APT),
por sus estrictas políticas con respecto a sus paquetes y la calidad de sus lanzamientos.
Estas prácticas permiten fáciles actualizaciones entre lanzamientos y una instalación y
remoción sencilla de paquetes. También utiliza un desarrollo y proceso de testeo abiertos.
Es desarrollado por voluntarios de todo el mundo, y apoyado por donaciones a través de
la Software in the Public Interest, una organización sin fines de lucro para el apoyo de pro-
yectos de software libre”.
Debian GNU/Linux
286
29.2.3. Ubuntu
“Ubuntu es un sistema operativo mantenido por Canonical y la comunidad de desarrolla-
dores. Utiliza un núcleo Linux, y su origen está basado en Debian. Está orientado al usua-
rio novel y promedio, con un fuerte enfoque en facilitar el uso y mejorar la experiencia del
usuario. Está compuesto de software múltiple normalmente distribuido bajo una licencia
libre o de código abierto. Estadísticas web sugieren que el porcentaje de mercado de Ubun-
tu dentro de distribuciones Linux es de aproximadamente el 49%, y con una tendencia a
subir como servidor web. Y un importante incremento activo de 20 millones de usuarios
para fines de 2011.
Su patrocinador, Canonical, es una compañía británica propiedad del empresario su-

dafricano Mark Shuttleworth que ofrece el sistema de manera gratuita y se financia por
medio de servicios vinculados al sistema operativo y vendiendo soporte técnico. Además,
al mantenerlo libre y gratuito, la empresa es capaz de aprovechar los desarrolladores de
la comunidad para mejorar los componentes de su sistema operativo. Extraoficialmente,
la comunidad de desarrolladores proporciona soporte para derivaciones de Ubuntu con
otros entornos: Kubuntu, Xubuntu, Edubuntu, Ubuntu Studio, Mythbuntu y Lubuntu.
Canonical además de mantener Ubuntu, también provee de una versión orientada a servi-
dores, Ubuntu Server, y una versión para empresas, Ubuntu Business Desk”.
29.2.4. Windows 7
“Es la versión más reciente de Microsoft Windows, línea de sistemas operativos producida
por Microsoft Corporation. Esta versión está diseñada para uso en PC, incluyendo equipos
de escritorio en hogares y oficinas, equipos portátiles, tablet PC, netbooks y equipos media
center. El desarrollo de Windows 7 se completó el 22 de julio de 2009, siendo entonces con-
firmada su fecha de venta oficial para el 22 de octubre de 2009 junto a su equivalente para
servidores Windows Server 2008 R2.
A diferencia del gran salto arquitectónico y de características que sufrió su antecesor,

Windows Vista con respecto a Windows XP, Windows 7 fue concebido como una actualiza-
ción incremental y focalizada de Vista y su núcleo NT 6.0, lo que permitió mantener cierto
grado de compatibilidad con aplicaciones y hardware en los que éste ya era compatible.
Sin embargo, entre las metas de desarrollo para Windows 7 se dio importancia a mejo-
rar su interfaz para volverla más accesible al usuario e incluir nuevas características que
permitieran hacer tareas de una manera más fácil y rápida, al mismo tiempo que realizó
esfuerzos para lograr un sistema más ligero, estable y rápido.
287
Diversas presentaciones ofrecidas por la compañía en 2008 se enfocaron en demostrar ca-

pacidades multitáctiles, una interfaz rediseñada junto con una nueva barra de tareas y un
sistema de redes domésticas simplificado y fácil de usar denominado ‘Grupo en el hogar’,
además de importantes mejoras en el rendimiento general del sistema operativo”.
29.2.5. Eclipse
“Eclipse es un entorno de desarrollo integrado de código abierto multiplataforma para
desarrollar lo que el proyecto llama ‘aplicaciones de cliente enriquecido’, opuesto a las
aplicaciones ‘cliente-liviano’ basadas en navegadores. Esta plataforma, ha sido usada tí-
picamente para desarrollar entornos de desarrollo integrados (IDE), como el IDE de Java
llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega como par-
te de Eclipse (son usados también para desarrollar el mismo Eclipse). Sin embargo, tam-
bién se puede usar para otros tipos de aplicaciones cliente, como BitTorrent o Azureus.
Eclipse es también una comunidad de usuarios, extendiendo constantemente las áreas

de aplicación cubiertas. Un ejemplo es el recientemente creado Eclipse Modeling Project,
cubriendo casi todas las áreas de Model Driven Engineering.
Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herra-
mientas para VisualAge. Ahora es desarrollado por la Fundación Eclipse, una organiza-
ción independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un
conjunto de productos complementarios, capacidades y servicios.
Eclipse fue liberado originalmente bajo la Common Public License, pero después fue reli-
cenciado bajo la Eclipse Public License. La Free Software Foundation ha dicho que ambas
licencias son licencias de software libre, pero incompatibles con la Licencia Pública Gene-
ral de GNU (GNU GPL)”.
29.2.6. Git
“Git es un software de control de versiones diseñado por Linux Torvalds, pensando en la
eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas
tienen un gran número de archivos de código fuente. Al principio, Git se pensó como un
motor de bajo nivel sobre el cual otros pudieran escribir la interfaz de usuario o front end,
como Cogito o StGIT. Sin embargo, Git se ha convertido desde entonces en un sistema de
control de versiones con funcionalidad plena. Hay algunos proyectos de mucha relevancia
que ya usan Git, en particular, el grupo de programación del núcleo Linux.
El mantenimiento del software Git está actualmente (2009) supervisado por Junio Hama-
no, quien recibe contribuciones al código de alrededor de 280 programadores”.
288
29.2.7. Bugzilla
“Bugzilla es una herramienta basada en web de seguimiento de errores (Bug Tracking Sys-
tem o BTS, por sus siglas en inglés), originalmente desarrollada y usada por el proyecto
Mozilla. Lanzado como software de código abierto por Netscape Communications en 1998,
Bugzilla ha sido adoptado por una variedad de organizaciones para su empleo en el se-
guimiento de defectos (errores), tanto para software libre como para software propietario.
Su licenciamiento es bajo la licencia pública de Mozilla.
Bugzilla permite organizar en múltiples formas los defectos de software, permitiendo el

seguimiento de múltiples productos con diferentes versiones, a su vez compuestos de múl-
tiples componentes. Permite además categorizar los defectos de software de acuerdo a su
prioridad y severidad, así como asignarles versiones para su solución.
También permite anexar comentarios, propuestas de solución, designar a responsables

a los que asignar la resolución y el tipo de solución que se aplicó al defecto, todo ello lle-
vando un seguimiento de fechas en las cuales sucede cada evento y, si se configura ade-
cuadamente, enviando mensajes de correo a los interesados en el error. Bugzilla utiliza
un servidor HTTP (como puede ser Apache) y una base de datos (normalmente, MySQL)
para llevar a cabo su trabajo. Los errores pueden ser enviados por cualquiera y pueden ser
asignados a un desarrollador en particular. Cada error puede tener diferente prioridad y
encontrase en diferentes estados, así como ir acompañado de notas del usuario o ejemplos
de código que ayuden a corregir el error.
La noción de ‘error’ en Bugzilla es muy general; por ejemplo, Mozilla.org lo utiliza también
para registrar las peticiones de nuevas funcionalidades, con lo que el espectro de cuestio-
nes sobre las que permite realizar un seguimiento se amplía”.
29.2.8. Tomcat
“Tomcat es mantenido y desarrollado por miembros de la Apache Software Foundation y
voluntarios independientes. Los usuarios disponen de libre acceso a su código fuente y a
su forma binaria en los términos establecidos en la Apache Software Licence. Las primeras
distribuciones de Tomcat fueron las versiones 3.0.x. Las versiones más recientes son las 7.x,
que implementan las especificaciones de Servlet 3.0 y de JSP 2.2. A partir de la versión 4.0,
Jakarta Tomcat utiliza el contenedor de Servlets Catalina. Tomcat es un servidor web con
soporte de Servlets y JSPs. Tomcat no es un servidor de aplicaciones, como JBoss o JOnAS.
Incluye el compilador Jasper, que compila JSPs convirtiéndolas en Servlets. El motor de
Servlets de Tomcat a menudo se presenta en combinación con el servidor web Apache.
289
Tomcat puede funcionar como servidor web por sí mismo. En sus inicios, existió la percep-
ción de que el uso de Tomcat de forma autónoma era sólo recomendable para entornos de
desarrollo y entornos con requisitos mínimos de velocidad y gestión de transacciones. Hoy
en día, ya no existe esa percepción y Tomcat es usado como servidor web autónomo en
entornos con alto nivel de tráfico y alta disponibilidad.
Dado que Tomcat fue escrito en Java, funciona en cualquier sistema operativo que dispon-
ga de la máquina virtual Java.
GIMP (GNU Image Manipulation Program) es un programa de edición de imágenes di-

gitales en forma de mapa de bits, tanto dibujos como fotografías. Es un programa libre y
gratuito. Forma parte del proyecto GNU y está disponible bajo la Licencia pública general
de GNU.
Es el programa de manipulación de gráficos disponible en más sistemas operativos (Unix,

GNU/Linux, FreeBSD, Solaris, Microsoft Windows y Mac OS X, entre otros).
La interfaz de GIMP está disponible en varios idiomas, entre ellos: español, inglés (el idio-
ma original), catalán, gallego, euskera, alemán, francés, italiano, ruso, sueco, noruego, co-
reano y neerlandés”.
29.2.9. Bluefish
“Bluefish es un software editor HTML multiplataforma POSIX y con licencia GPL, lo que lo
convierte en software libre.
Bluefish está dirigido a diseñadores web experimentados y programadores, y se enfoca en

la edición de páginas dinámicas e interactivas. Es capaz de reconocer diversos lenguajes
de programación y de marcas.
Bluefish corre en muchos de los sistemas operativos compatibles con POSIX (Portable
Operating System Interface) tales Linux, FreeBSD, MacOS-X, OpenBSD, Solaris y Tru64.
Emplea principalmente las bibliotecas GTK y C posix. La última versión que trabajó con
GTK 1.0 o 1.2 es la 0.7. La versión actual requiere como mínimo GTK versión 2.0 (o superior),
Libpcre 3.0 (o superior), Libaspell 0.50 o superior (opcional) para corrección de ortografía
y Gnome-vfs (opcional) para archivos remotos.
Es importante anotar que el programa no es oficialmente parte del proyecto Gnome, pero
es utilizado a menudo en dicho entorno.
290
Los usuarios también pueden acceder a los recursos en línea, tales como servidores FTP o
directorios WebDAV, de forma transparente, a través de Gnome VFS, una capa de abstrac-
ción al sistema de archivos.
El nombre y logo de Bluefish (pez azul) fue propuesto por Neil Millar, quien lo sugirió al
equipo de trabajo e inmediatamente los cautivó. Bluefish es un animal (pez) que se des-
plaza en cardúmenes numerosos y cerca de la costa. Es evidente que su nombre llama a la
integración y a la compartición, ideales en el software libre.
Bluefish cuenta con características tales como rapidez, posibilidad de abrir múltiples ar-
chivos simultáneamente, soporte multiproyecto, soporte para archivos remotos mediante
Gnome-vfs, marcado de sintaxis personalizable basado en expresiones regulares com-
patibles con Perl, soporte para subpatrones y patrones predefinidos (para HTML, PHP,
Javascript, JSP, SQL, XML, Python, Perl, CSS, ColdFusion, Pascal, R, Octave/Matlab),
diálogos para etiquetas HTML, asistentes para creación fácil de documentos, creación
de tablas, marcos (frames), soporte para múltiples codificaciones, trabajo con diferentes
juegos de caracteres, numeración de líneas, menús desplegables, barras de herramientas
configurables, diálogo para insertar imágenes, buscador de referencia de funciones, inte-
gración personalizable con varios programas (Make, Javac, etc.), resaltado de sintaxis (C,
Java, JavaScript, Python, Perl, ColdFusion, Pascal, R y Octave), traducciones completas a
aproximadamente 22 idiomas, entre ellos: portugués brasileño, búlgaro, chino, danés, finés,
francés, alemán, húngaro, italiano, noruego, polaco, portugués, español, sueco, japonés, y
tamil.
Google Apps es un servicio de Google que proporciona de manera independiente las ver-
siones personalizadas de varios productos de Google con un nombre de dominio persona-
lizado. Cuenta con varias aplicaciones web con funciones similares a las suites ofimáticas
tradicionales: Gmail, Google Groups, Google Calendar, Google Talk, Google Docs y Google
Sites. Fue la visión de Rajen Seth, un empleado de Google, que más tarde desarrolló Chro-
mebooks”.
29.2.10. Google Apps

“Google Apps es gratuito y ofrece la misma cantidad de almacenamiento que en las cuen-
tas particulares de Gmail. Google Apps para empresas ofrece más almacenamiento de
correo electrónico y está disponible por una cuota anual/cuenta de usuario. Google Apps
para educación es gratuito y combina las características de las ediciones Standard y Bu-
siness.
Además de las aplicaciones compartidas (calendario, documentos, etc.), existe Google

Apps Marketplace, que es una tienda virtual para los usuarios de Google Apps. Contiene
diversas aplicaciones, tanto gratuitas como de pago, que se pueden instalar para persona-
lizar el usuario de Google Apps”.
291
29.2.11. Asterisk
“Asterisk es un programa de software libre (bajo licencia GPL) que proporciona funcionali-
dades de una central telefónica (PBX). Como cualquier PBX, se puede conectar un número
determinado de teléfonos para hacer llamadas entre sí e incluso conectar a un proveedor
de VoIP o bien a una RDSI tanto básicos como primarios.
Mark Spencer, de Digium, inicialmente creó Asterisk y actualmente es su principal de-

sarrollador, junto con otros programadores que han contribuido a corregir errores y aña-
dir novedades y funcionalidades. Originalmente desarrollado para el sistema operativo
GNU/Linux, Asterisk también se distribuye actualmente en versiones para los sistemas
operativos BSD, Mac OS X, Solaris y Microsoft Windows, aunque la plataforma nativa
(GNU/Linux) es la que cuenta con el mejor soporte de todas.
Asterisk incluye muchas características que anteriormente sólo estaban disponibles en

costosos sistemas propietarios PBX, como buzón de voz, conferencias, IVR, distribución au-
tomática de llamadas y otras muchas. Los usuarios pueden crear nuevas funcionalidades
escribiendo un dialplan en el lenguaje de script de Asterisk o añadiendo módulos escritos
en lenguaje C o en cualquier otro lenguaje de programación, soportado en GNU/Linux.
Para conectar teléfonos estándares analógicos son necesarias tarjetas electrónicas tele-
fónicas FXS o FXO fabricadas por Digium u otros proveedores, ya que para conectar el
servidor a una línea externa no basta con un simple módem.
Quizá lo más interesante de Asterisk es que reconoce muchos protocolos VoIP como pue-
den ser SIP, H.323, IAX y MGCP. Asterisk puede interoperar con terminales IP actuando
como registrador y como gateway entre ambos.
Asterisk se empieza a adoptar en algunos entornos corporativos como una gran solución
de bajo coste junto con SER (Sip Express Router)”.
Dato importante
La elección de cualquier elemento que intervenga en nuestros proyectos de desarro-

llo puede tener mil variables que han de ser analizadas con sumo cuidado desde el
inicio para evitar las sorpresas en el futuro.
292
29.3.Resumen del tema

• El planteamiento de un caso.
• La resolución: planteamiento de toda una arquitectura para dar soporte a una pe-
queña startup:
• Sistemas operativos.
• Suite ofimática.
• Entorno de desarrollo.
• Gestión de errores.
• Diseño.
• Correo.
293
30. Tipología de aplicaciones

“Aplicaciones a medida: creadas expresamente para dar soporte a
un proceso de negocio; ce-rradas: creadas por terceros que venden
a aquéllos que las quieran usar; y abiertas: crea-das por comuni-
dades que se sustentan bajo los principios de la compartición de
conocimiento.”
30.1. Definición de aplicación

Empecemos por definir qué es una aplicación. Es un programa informático que permite
utilizar el ordenador con un fin específico. Esto lo diferencia de otros tipos de programas,
como puedan ser los leguajes de programación que se utilizan para realizar software o los
sistemas operativos que valen como capa para facilitar y gestionar los recursos de hard-
ware que se pone a disposición de las aplicaciones que corren sobre él.
Como ejemplo de aplicaciones que tienen una función específica y que son más popula-
res entre los usuarios, podemos citar los procesadores de texto, las hojas de cálculo, los
navegadores, las bases de datos, los programas de diseño gráfico, los clientes de correo y
así un largo etcétera de opciones.
30.2. tipología de aplicaciones

Podemos destacar tres tipologías:
• Aplicaciones a medida. Aquellas aplicaciones que se realizan para cubrir una fun-
cionalidad concreta y particular del negocio. Éstas pueden estar desarrolladas por
personal interno de la compañía o también se puede subcontratar su desarrollo a
terceros que se encargarán de todas las fases, entregando al final una aplicación
llave en mano.
Antiguamente, este tipo de aplicaciones era muy común y las compañías se lanza-
ban a intentar automatizar algún proceso de negocio a base de desarrollos a medi-
da. Pese a que esto parece lo ideal porque al final realizamos un aplicativo que se
adecua como un guante a nuestros procesos de negocio, en la actualidad, excepto
casos particulares y sectores concretos, muchas empresas intentan no realizar apli-
caciones a medida por los inconvenientes que éstas pueden ocasionar.
294
Por un lado, si se desarrollan dentro de la compañía, se proveen de una serie de

recursos capaces de mantener la aplicación, lo cual puede que no sea el objetivo
de nuestro negocio. También, por norma general, muchas de estas aplicaciones
acaban siendo una caja negra por falta de documentación o porque las personas
que lo desarrollaron ya no están en la compañía.
Otro aspecto que ha hecho caer en desuso este tipo de aplicaciones en gran parte
de la industria es la proliferación de grandes paquetes software que se adaptan
perfectamente a los procesos de negocio, como puedan ser los grandes paquetes
ERP, porque al final, pese a que muchas de las empresas se plantean que sus pro-
cesos sean únicos después de un análisis algo exhaustivo, se dan cuenta que esto
en gran medida no es cierto. Todo esto no significa que el desarrollo a medida sea
malo, sino que se ha de considerar con sus pros y sus contras antes de acudir a este
tipo de soluciones.
• Caso práctico. En su momento, una empresa dedicada al sector de la joyería se

planteó modernizar sus procesos que hasta entonces habían sido bastante ru-
dimentarios y sin ningún control. Para ello, se pensó implantar un ERP que les
ayudase a formalizar los procesos y poner algo de orden. Después de analizar
diferentes alternativas, se desestimó la opción de implantar el ERP y se decidió
realizar un software a medida. Para ello, se contrató un equipo de desarrollo que
después de muchas dificultades y retrasos continuos consiguió crear e implan-
tar el software desarrollado. Una vez finalizada la implantación, la empresa deci-
dió mantener a una única persona del equipo inicial que durante un tiempo se
ha dedicado al evolutivo y correctivo del software.
• Pros. El software es como un guante a medida para la compañía, se adapta per-

fectamente a los procesos de negocio.
• Inconvenientes. Alta dependencia de la persona que se quedó a cargo del aplica-

tivo. Nula posibilidad de encontrar en el mercado perfiles que puedan mantener
el aplicativo en caso de marcha de la persona actual. Puesto que esta persona es
la única que conoce el modelo de datos del aplicativo a medida, se hace impres-
cindible en caso de intentar evolucionar hacia otro sistema, como pueda ser un
ERP de amplia difusión en el mercado.
• Aplicaciones cerradas o propietarias. Son las aplicaciones de las cuales no dispo-

nemos del código y, como tal, no pueden ser modificadas para intentar adaptarlas
a algún caso particular. Pese a que este tipo de aplicaciones son en teoría no mo-
dificables, la tendencia actual en el mercado del software es que las aplicaciones
de este tipo, gracias a sistemas de configuración interna, puedan adaptarse a cir-
cunstancias extraordinarias que antes hubieran supuesto un desarrollo a medida.
295
También podemos encontrar aplicaciones cerradas que, pese a que no tener acceso
al código fuente, dentro de su entorno nos proveen con su propio lenguaje de pro-
gramación y nos permiten la creación de rutinas para aprovechar las funcionalida-
des de una forma más particularizada. Por ejemplo, los paquetes de ERP como SAP
funcionan de esta forma, esto les confiere una flexibilidad increíble para adaptarse
al proceso de negocio de la compañía.
• Caso práctico. La compañía C hace diez años decidió implantar un sistema de

correo centralizado para soportar el correo de los trabajadores. Para ello, montó
una infraestructura de servidores y compro un software propietario e implantó
el cliente de correo en cada uno de las estaciones de trabajo de sus empleados.
• Pros. Sistema amigable y ya conocido por los trabajadores, lo que hizo el cambio
de un sistema a otro menos traumático. Sistema robusto y con un mantenimien-
to por parte del proveedor. Solución conocida ampliamente en el mercado, lo que
facilita encontrar administradores en caso de ser necesario substituir al actual.
• Inconvenientes. Pago de licencias por los clientes y el servidor. Dependencia

total del software, al ser un software propietario no se tiene acceso a los ficheros
donde se almacena los correos, lo que implica que, si la empresa quisiera, por
ejemplo, pasar a algún tipo de correo en la nube, tendría que acudir pagando a
un software de terceros para poder llevar el historial de correos.
• Aplicaciones abiertas o de código abierto. Son aquéllas de las que poseemos el

código fuente y lo podemos adaptar a su funcionamiento para cubrir una serie
de funcionalidades particulares de nuestro negocio. Este tipo de aplicaciones, por
norma general, son creadas y compartidas por grupos de desarrollo o empresas
que ponen a disposición todo el código de la aplicación y sacan su beneficio de la
consultoría que éstas puedan vender. Por norma general, este tipo de aplicaciones
están protegidas por licencias de tipo GPL, que obligan (por ejemplo, dependiendo
de la modalidad de licencia elegida) a cosas como la publicación del código fuente
una vez realizadas las modificaciones. Esto, junto al crecimiento de internet, permi-
te que podamos encontrar todo tipo de aplicaciones, incluso sistemas operativos
bajo la fórmula de código abierto.
• Caso práctico. La empresa C, dedicada al sector del telemarketing durante mu-

cho tiempo, ha mantenido un sistema basado en electrónica, de la casa Avaya,
por su robustez y fiabilidad. Éste ha estado en funcionamiento tanto para sus
centros de atención al cliente como para su estructura.
296
El sistema de telefonía principalmente está basado en VoIP. Por esto y por un

tema de I+D, el departamento de comunicaciones junto con el departamento
de desarrollo empezaron a investigar la vía para poder implantar una PBX por
software para la estructura, liberando las centralitas Avaya y ahorrando consi-
derablemente en licencias. Después de un tiempo de investigación, se decidió
implantar la solución de código abierto Asterisk bajo servidores Debian. Se in-
terconectó la centralita Asterisk al de Avaya y se portó toda la telefonía IP de la
estructura a la nueva centralita.
• Pros. Ahorro considerable en licencias. Gran base de conocimiento en internet

para la búsqueda de incidencias. Gran compatibilidad con los sistemas analógi-
cos y digitales. Gran estabilidad y constante revisión del software.
• Inconvenientes. Necesidad de perfiles más cualificados para la administración,

tanto de la centralita Asterisk como del sistema Debian. Pese a ser una solución
muy estable y en constante revisión, aún le falta tiempo para ponerse a la altura
de soluciones comerciales como las de Avaya.
30.3. Tendencias en aplicaciones

En la actualidad, podemos remarcar tres tendencias:
• Open Source. Durante mucho tiempo, las empresas han sido reacias al uso de apli-
caciones de código abierto alegando motivos como su bajo soporte o la necesidad
de perfiles muy específicos. El hecho de no encontrar detrás de un software a una
empresa que pudiera dar soporte en caso de problema echaba para atrás a mu-
chas empresas a la hora de adoptar este tipo de herramientas. Pese a esta resisten-
cia, muchas empresas usaban casi inconscientemente software de código abierto,
lenguajes como Java o entornos de desarrollo abiertos (como Netbeans o Eclipse,
que han tenido gran difusión), por no hablar de los navegadores que han hecho la
competencia durante mucho tiempo a Internet Explorer. Éstos y otros softwares
han hecho ver que el software de código abierto en muchas ocasiones puede ser
incluso mejor que el software de propietarios con costes insignificantes.
Gracias a esta confianza, podemos ver como cada vez más empresas han empezado
a montar sus servidores bajo distribuciones de código abierto como Linux, que
ha demostrado ser altamente estable frente a otros sistemas operativos. Cada vez
más gente se acerca al software libre por temas económicos y está venciendo esta
resistencia de la industria durante muchos años.
297
• Aplicaciones móviles. Es el tipo de aplicación que más ha crecido en los últimos

años. Con la explosión de los smartphones y la entrada en el mercado de la tele-
fonía de las grandes compañías como son Microsoft, Apple y Google, este tipo de
aplicaciones se ha popularizado enormemente pese a mantener estrategias dife-
rentes en el mercado. Conforme avanzan tecnológicamente nuestros móviles y
más cosas pueden hacer, más aplicaciones aparecen en el mercado para satisfacer
las necesidades del usuario. En la actualidad y según Gartner, las aplicaciones más
valoradas en el entorno móvil son:
• Transferencia de dinero mediante SMS.
• Servicios basados en la localización.
• Búsquedas desde el móvil (en especial, dirigido a compras).
• Navegadores para móviles.
• Monitorización médica.
• Aplicaciones para pagos.
• Servicios de comunicación por proximidad.
• Publicidad.
• Aplicaciones de mensajería instantánea.
• Aplicaciones para música.
La lista nos da una visión más o menos de la temática tan diversa que nos pode-
mos encontrar. Se calcula que la tienda de Apple tiene actualmente del orden de
600.000 aplicaciones, lo que nos da una idea de la cantidad tan enorme de la que
estamos hablando. Esta popularización de las aplicaciones móviles y las estrate-
gias de tiendas de aplicaciones de los grandes de la industria han fomentado nue-
vos modelos de negocio.
• Aplicaciones en cloud computing. Desde siempre hemos observado el modelo tra-

dicional de aplicaciones, donde teníamos una aplicación que se alojaba en la má-
quina y el usuario podía lanzarla y trabajar con ella sin problemas. Si otro usuario
quería usar esta aplicación, tenía que tener una copia en su máquina y trabajar con
ella.
298
Esto tiene inconvenientes, como que la aplicación no es independiente del tipo de

máquina sobre el que corre, con lo cual es necesario realizar versiones diferentes
en función del sistema operativo; otro gran inconveniente es que, si queremos rea-
lizar una actualización, ésta se ha de realizar sobrescribiendo la aplicación en cada
una de las máquinas.
Más tarde, apareció otro modelo de aplicación, creadas en formato web, de forma
que una única copia de la aplicación corría sobre un clúster de máquinas, dando
servicio a todo aquél que quisiera acceder a los servicios que la aplicación proveía.
Tenía la ventaja de ser accesible desde cualquier sitio y actualizada de manera más
sencilla, al existir una aplicación centralizada. Por el contrario, las limitaciones de
interfaz de los navegadores hacían que dichas aplicaciones fueran algo limitadas
en cuanto a funcionalidad. Como resultado, ha aparecido el modelo de aplicacio-
nes en la nube, que nos provee de un entorno de ejecución donde las máquinas y el
sistema operativo donde se ejecuten son invisibles para nosotros, y de un entorno
en la red donde se ejecuta nuestro aplicativo. Este entorno es elástico y podemos
definir los recursos de los que ha de disponer sin preocuparnos del hardware que
hay detrás.
Otra ventaja que ha heredado de los sistemas web es la evolución hacia el Web 2.0,
de forma que podemos crear aplicaciones RIA, que permite que las interfaces de
los aplicativos webs se parezcan cada vez más a las aplicaciones nativas, lo que ha
fomentado la creación de aplicaciones que con las limitaciones anteriores hubie-
ran sido impensable portar al entorno web.
Dentro del cloud computing, podemos encontrar varios modelos:
• Software as a Service (SaaS). En español software como servicio. Modelo de dis-

tribución de software donde una empresa sirve el mantenimiento, soporte y ope-
ración que usará el cliente durante el tiempo que haya contratado el servicio. El
cliente usará el sistema alojado por esa empresa, la cual mantendrá la informa-
ción del cliente en sus sistemas y proveerá los recursos necesarios para explotar
esa información. Ejemplos: Salesforce, Basecamp.
• Infrastructure as a Service (Iaas). En español infraestructura como servicio. Mo-

delo de distribución de infraestructura de computación como servicio, normal-
mente mediante una plataforma de virtualización. En vez de adquirir servidores,
espacio en un centro de datos o equipamiento de redes, los clientes compran
todos estos recursos a un proveedor externo de servicios. Una diferencia fun-
damental con el hosting virtual es que el aprovisionamiento de estos servicios
se hace de manera integral a través de la web. Ejemplos: Amazon Web Services
EC2 y GoGrid.
299
• Platform as a Service (PaaS). En español plataforma como servicio. Aunque sue-

le identificarse como una evolución de SaaS, es más bien un modelo en el que se
ofrece todo lo necesario para soportar el ciclo de vida completo de construcción
y puesta en marcha de aplicaciones y servicios web completamente disponibles
en internet. Otra característica importante es que no hay descarga de software
que instalar en los equipos de los desarrolladores. PasS ofrece múltiples servi-
cios, pero todos aprovisionados como una solución integral en la web. Ejemplos:
Amazon Web Services y Google App Engine.
Como nota común a todos ellos, este tipo de servicios se factura en función de los recur-
sos consumidos, que normalmente son el reflejo del nivel de actividad del sistema.

• Tipología de aplicaciones:
• Aplicaciones a medida: creadas expresamente para dar soporte a un proceso de

negocio.
• Aplicaciones cerradas o propietarias: creadas por terceros que venden a aquéllos

que las quieran usar.
• Aplicaciones abiertas o de código abierto: creadas por comunidades que se sus-

tentan bajo los principios de la compartición de conocimiento.
• Tendencias en aplicaciones:
• Aplicaciones Open Source: cada día más usadas en los ámbitos empresariales,
gracias a su amplio soporte y los ahorros de costes que nos puede aportar a
nuestro negocio.
• Aplicaciones móviles: mercado creciente gracias al desarrollo de la movilidad.
• Aplicaciones cloud computing: accesibles desde cualquier lugar, desvinculando

el hardware del software por completo.
Dato importante
Las aplicaciones abiertas o de código abierto permiten un considerable ahorro a la

empresa en cuanto a la adquisición de licencias se refiere.
300
31. Integración de sistemas

“Si la mejora de nuestros procesos de negocios y aplicaciones re-
dunda en una mejora de la organización, nuestra arquitectura ha
de ser flexible y convertirse en el vehículo para que ambas mejoren.”
31.1. Arquitectura de sistemas

Se entiende por arquitectura de sistemas en un proyecto informático a la conjunción pla-
nificada y ordenada de elementos software y hardware para cumplir con una determinada
funcionalidad.
Es muy común encontrar que la arquitectura esté formada por cuatros capas:
• La capa de negocio: donde se desempeñan las actividades diarias de la organiza-

ción.
• La capa de aplicaciones: las aplicaciones que dan servicio a la capa de negocio.
• La capa de arquitectura: soporta a la capa de aplicaciones para su correcto funcio-

namiento.
• La capa de hardware: es la capa más baja, soporta el funcionamiento de la capa de

arquitectura.
Cada capa da servicio a la que está inmediatamente por encima. Esta distribución en ca-
pas permite definir el rol de cada arquitectura dentro de nuestra organización.
Desde el punto de vista de la empresa, interesa que nuestra arquitectura de sistemas pue-
da evolucionar, si la mejora de nuestros procesos de negocios y aplicaciones redunda en
una mejora de la organización, nuestra arquitectura ha de ser flexible y convertirse en el
vehículo para que ambas mejoren.
301
Por ejemplo, la arquitectura de sistemas de una empresa de telemarketing podría ser:
• A nivel hardware: servidores varios (de ficheros, con funciones de red, base de da-
tos, etc.), la infraestructura VoIP (teléfonos, centralita, gateway), la electrónica de
red (switch y routers) y los ordenadores de los usuarios.
• A nivel de arquitectura: los servidores Internet Information Service, Apache o

Tomcat para dar servicio a las aplicaciones web.
• A nivel de aplicaciones: el ERP, el CRM, el sistema CTI, etc.
• A nivel negocio: desde la atención al cliente de algún operador hasta la venta de

productos de salud a través del teléfono, mediante campaña de emisión.
31.2. Integración de sistemas

¿Qué es la integración de sistemas? Las empresas tienen múltiples aplicaciones implan-
tadas que pueden ser de creaciones propias o compradas a terceros, que dan soporte a
sus procesos de negocio. Es muy común, y todo el que se ha movido en este ambiente se
ha encontrado situaciones donde estos sistemas no se comuniquen entre sí; por ejemplo,
que el CRM de la empresa no pueda acceder al antiguo software casero donde la gente de
marketing guardaba los contactos de los clientes en potencia o que el nuevo módulo de
recursos humanos del flamante nuevo ERP de España no pueda compartir información
con el ERP de Chile porque son de fabricantes diferentes y no hay forma que se entienda
por mucho que nos dijeran cuando lo compramos que se integraba con cualquier sistema.
Estas situaciones se dan muy a menudo y es aquí donde entra la integración de sistemas,
que es en muchas ocasiones la creación de aplicaciones o procesos que faciliten la comu-
nicación entre los diferentes sistemas que dan soporte a nuestro negocio. Finalmente, las
principales motivaciones para la integración son:
• Cuando no es posible desarrollar una aplicación que nos ofrezca todas las funcio-
nalidades que necesitamos para cubrir nuestros procesos de negocio. En este caso,
optamos por montar varias aplicaciones que por partes nos solucionen las funcio-
nalidades que queremos cubrir, y luego las integramos.
• Cuando el coste del desarrollo es superior al de mantener la integración de los

diferentes sistemas.
302
• Cuando nos obligan factores externos (regulatorios o legales). Por ejemplo, la ne-
cesidad de guardar determinados documentos, por ejemplo, en gestiones telefóni-
cas, como pueden ser las grabaciones de ventas.
• Cuando tenemos que conectar nuestros sistemas con los sistemas de un cliente.
Un ejemplo de integración es:
La empresa de telemarketing TeleA tiene un cliente del ramo de los seguros, la empresa
SegurB. Ésta ofrece un producto de salud cuyo proceso de venta es bastante sencillo: la
empresa TeleA llama a la persona y, si ésta accede, se le realiza una preventa. Esta preven-
ta es remitida a día vencido a la empresa SegurB vía fichero .txt con un formato estableci-
do entre las dos empresas. Cuando SegurB recibe este fichero al día siguiente, analiza el
fichero, lo procesa y genera una serie de acciones, entre las que está generar otro fichero
para otra empresa llamada MediC que se encarga de realizar un cuestionario médico vía
telefónica. Cuando MediC realiza este cuestionario, manda los resultados vía otro fichero
a SegurB y, en función de los resultados, da la venta como buena y asegura al comprador.
Desde que se hace la preventa por TeleA hasta que SegurB da al asegurado por válido
pueden pasar días en el mejor de los casos, lo que da una sensación de lentitud en el
proceso y hace que la satisfacción del cliente no sea del todo buena porque éste está sin
cubrir durante todo el proceso.
Para ello, la empresa TeleA ideó conjuntamente un con SegurB y MediC un sistema para
acelerar el proceso. Para TeleA era sencillo transferir la llamada a MediC una vez se hi-
ciera la preventa, el problema principal era que toda la información recogida por TeleA
(nombre, apellidos, etc.) no podía ser nuevamente preguntada por MediC, porque daría
mala imagen ante el cliente, con lo cual se ideó un sistema en que los operadores telefó-
nicos enviaran la información a MediC antes de enviar la llamada, así que cuando MediC
recibía la llamada ya disponía en su sistema de toda la información del cliente.
Este sistema era un aplicativo que recogía la información del sistema CTI de TeleA y,
mediante una llamada a un web service implementado por MediC, se le enviaba la in-
formación que se integraba inmediatamente en el sistema de éste. Fuera del alcance del
ejemplo, quedan los detalles de qué pasaba cuando la llamada transferida por TeleA no
era cogida por MediC u otros posibles problemas en la implementación de sistemas como
éstos. Pero, pese a estos inconvenientes, el aumento de la satisfacción del cliente fue enor-
me y se pasó de un proceso de días, incluso en ocasiones más de una semana, a un proce-
so de un día o dos en el peor de los casos.
303
Según las necesidades, podemos diferenciar la integración en tres tipos:
• Integración por necesidades de hardware: esta integración se produce con disposi-

tivos especializados en tareas específicas.
• Integración con TPV, TPL, etc.
• Integración con la telefonía.
• Integración con dispositivos industriales.
• Integración con dispositivos de grabación.
• Integración con PDAs.
• Integración por necesidades de software:
• Cuando un proceso de negocio se soporta en varias aplicaciones que no se en-

tienden entre sí y es necesario para este soporte que se entiendan.
• Aplicaciones con funcionalidades que a priori no tienen nada que ver, pero que
por necesidades han de compartir negocio.
• Por seguridad, se puede dar la necesidad de compartir información entre aplica-

ciones a través de un medio de comunicación no soportado por dichas aplica-
ciones.
• Integración por motivos legales:
• Derecho del ciudadano a interactuar electrónicamente con la administración.
• Factura de la Agencia Tributaria.
• Mercados regulados (gas, electricidad, etc.).
304
31.3. Patrones de integración

El objetivo de los patrones de integración es simplificar el diseño e implementación a la
hora de crear soluciones.
31.3.1. Patrones principales (básicos)

• One way. El patrón más básico, se constituye de un emisor y un receptor. Su funcio-
namiento es simple: el emisor manda un mensaje al receptor.
Figura 1. One way.

• Request/Response. Similar al anterior, pero en este caso el receptor proporciona

respuesta. Su funcionamiento es también simple: el emisor manda un mensaje al
receptor y éste responde con otro mensaje informando al emisor si la recepción ha
sido satisfactoria o errónea.
Figura 2. Request/Response.
• Publish/Subscribe. Este patrón añade un elemento llamado hub al sistema, que se

encarga de dirigir la información que los emisores mandan a una serie de recep-
tores que están conectados al hub. La forma de funcionar es: el emisor remite un
mensaje al hub. Éste lo recoge y, en función del destinatario, es redirigido hacia
uno o varios subscriptores.
305
Los patrones básicos son la base de funcionamiento de otros más complejos y que
quedan fuera del ámbito de este documento, pero es interesante nombrarlos para
que le suenen al lector:
• Robust Out Only: modo de transmisión síncrono. Modo de proceso asíncrono/

desacoplado.
• Robust Out Only with deferred Acknowledgement (V1): modo transmisión asín-
crona. Modo de Proceso asíncrono/ desacoplado.
• Out with deferred In (v1): modo transmisión asíncrono. Modo de proceso asín-
crono/desacoplado (correlacionado).
• Our with deferred In (v2): modo transmisión síncrono. Modo de procesos asín-
crono/desacoplado (correlacionado).
31.3.2. Ejemplo de patrones de integración

La empresa GasA tenía su negocio principalmente en Barcelona y alrededores, y le re-
presentaba un esfuerzo enorme realizar la lectura de los contadores de gas. El tiempo y
esfuerzo dedicado a la lectura de contadores de los clientes de la ciudades y pueblos com-
pensaba, pero existía una serie de clientes que vivía a las afueras junto con industrias que
estaban a una buena distanciada de la ciudad que requerían de mucho tiempo y esfuerzo
para realizar las lecturas.
Se plantearon muchas ideas, pero las principales coincidían en el hecho de que tenía que
instalarse contadores con algún tipo de conexión a alguna red que permitiera consultar
esta información sin tener que desplazarse hasta donde estaban situados. El tema era ver
qué red era lo suficientemente amplia y potente como para poder soportar algo así. La
única viable en ese momento por difusión era la telefonía móvil.
El siguiente problema fue qué patrón se usaría para comunicar con los contadores. El cos-
te de tener los contadores siempre conectados a la red telefónica era inviable, con lo cual
se procedió inicialmente a establecer un patrón de integración en este escenario del tipo
One way. De forma que todos los contadores se conectaban a un servidor ftp en una deter-
minada hora una vez al mes y dejaban el fichero que habían generado con la información
del consumo. Todos estos ficheros se recolectaban por un sistema central para generar las
facturas por el consumo realizado por el cliente.
306
El primer problema que se encontraron fue que, al conectarse todos a la vez, saturaban
la conexión de la empresa y se desechaban ficheros que no llegaban. Como el sistema no
tenía ningún tipo de notificación hacia los contadores para que éstos supieran que se ha-
bía recibido el fichero, lo que empezó a suceder es que lo que no se cargaba en la factura
del mes podía ser cargado dos meses después con el consecuente enfado del cliente al
no entender porque se le cobraba un acumulado en vez del cobro mensual, como se hacía
habitualmente.
Después de este primer intento de aproximación, la empresa se decidió por evolucionar

y decidió pasar a otro patrón algo más complejo, en este caso, se decantó por Request/
Response. De forma que ahora los contadores, cuando se conectan, esperaran una res-
puesta por parte del sistema de recolección. Puesto que se cambió el patrón, el sistema
de ftp ya no valía y se implementó una aplicación que esperaba la conexión de los conta-
dores, recibía el fichero con la información y respondía al contador con el resultado de la
transferencia. En caso de ser negativa, éste lo volvía a intentar, así hasta conseguirlo. El
problema de esta implementación, una vez más, fue la saturación en el servidor a causa de
la conexión simultánea de una cantidad de contadores que la red no soportaba. Para so-
lucionar esto, la hora de conexión de los contadores se distribuyó aleatoriamente durante
un par de días, de forma que, al distribuirse las conexiones, el sistema podía trabajar sin
la sobresaturación inicial.
31.4. Problemática de la integración

Nos encontramos en un entorno con varios sistemas funcionando en nuestra organiza-
ción, dando apoyo a los procesos de negocio. Estos sistemas no siempre se tienen que
entender entre ellos. Es muy común que estos procesos de negocio, en algún momento
concreto de la vida de la organización, necesiten de la colaboración de ambos sistemas
para poder funcionar o que nuestro proceso de negocio, soportado por una serie de apli-
caciones, se tenga que extender hacia fuera interactuando con sistemas de terceros. Esto
no siempre sencillo y rápido. Cuando emprendemos un proyecto de esta clase, nos encon-
tramos problemas que hemos de prever y solucionar.
Problemas habituales que podemos encontrar:
• Problemas de seguridad. Como en todo traspaso de información, siempre hay un

momento donde la información es más vulnerable (en la transmisión). Por eso, es
importante asegurar el canal. Ejemplo: la empresa que envía información personal
de los clientes a otra tercera vía internet. Enviar información sensible por internet
conlleva graves riesgos, si estas compañías no aseguran el canal de comunicación
mediante algún tipo de tecnología, la información es susceptible de ser capturada.
307
Problemas:
• Ataques externos: DoS, Smurf, SQL injection, etc.
• Ataques internos: pese a lo que se pueda pensar, los mayores problemas de segu-
ridad son los causados por los usuarios que están dentro de la red.
• Manipulación de la información.
Soluciones:
• Asegura el canal mediante el uso de protocolos seguros como http(s), ftp(s) o

con la contratación de líneas punto a punto. Implantar la necesidad de sistemas
de autentificación como certificados, usuario/password. Usar tecnologías de en-
criptación o firma digital.
• Se han de asegurar las herramientas de integración impidiendo el acceso a todo

usuario no autorizado.
• La manipulación de la información es algo complicado no al alcance de cual-

quiera, se ha de hacer énfasis en securizar los puntos desde donde fluye la infor-
mación.
• Problemas de diferentes tecnologías. Cuando nos encontramos con aplicaciones

diferentes dentro de la organización, éstas no tienen porque compartir absoluta-
mente nada. Puesto que no están diseñadas a tal efecto, nos encontramos entonces
que tampoco tienen porqué tener una tecnología común que facilite la integración.
Ejemplo: podríamos tener dos aplicativos donde uno de ellos soportase algún tipo
de entrada por web service y otro aplicativo que, como máximo, su exportación
de información la realizara mediante un fichero de texto plano. Ambas son tec-
nologías muy diferentes de intercambio de información, las cuales seguramente
requerirían de algún tipo de desarrollo que interpretase el fichero y lo enviara al
web service.
• Diferencias en canales de comunicación. Podemos encontrar multitud de tipos

de canales de comunicaciones, desde el uso de protocolos de comunicación como
http(s), ftp(s), ssh hasta canales que son simplemente una conexión a una base de
datos o una comunicación directa entre aplicaciones a través de la memoria prin-
cipal del ordenador.
308
El canal de comunicación, normalmente, es la primera elección al emprender un

proyecto de integración; es importante, puesto que sustentará todo el intercambio
de información y, si éste no cumple con ciertas propiedades, será imposible con-
trolar errores o monitorizar. El canal, por tanto, vendrá impuesto en ocasiones por
la aplicación que queramos integrar o por petición expresa de un cliente que nos
pida, por ejemplo, que se haga a través de http(s).
Problemas:
• El canal impactará muy directamente no sólo en el control de los errores o su

monitorización, también en el rendimiento y la estabilidad del sistema. Imagi-
nemos que nuestro canal es una comunicación móvil en un área de cobertura
dudosa, esto generaría muchos problemas al emprender la comunicación.
• No siempre es posible elegir el canal que se quiere porque el precio puede ser
desorbitado. En pos de la seguridad, muchas veces se realizan proyectos donde
se selecciona un canal de lo más seguro pero que tiene un coste altísimo.
Soluciones:
• En este caso, todo depende de si el canal es escogido o impuesto por un cliente.

Si es impuesto, no queda otra que intentar adaptarse lo mejor posible y estable-
cer todas las medidas para paliar cualquier efector adverso por la imposición
del canal. Si lo seleccionamos nosotros, tenemos que encontrar en equilibrio
entre los factores requiera nuestro proyecto: seguridad, rendimiento, estabilidad
y coste.
• En ocasiones, el sobrecoste puede hundir un proyecto, así que hay que ser muy
consciente de la información que se va a transferir, qué sentido tiene montar una
línea punto a punto con los consiguientes gastos si lo que vamos a enviar no
contiene información sensible.
• Diferencia en formatos de mensajes. Ésta es una de las diferencias que puede lle-
gar a dar más quebraderos de cabeza. Podríamos hacer el símil de la torre de Babel
para expresar el problema que nos podemos encontrar:
• Tenemos formatos estándares, como EDIFAC, EDITRANS.
• Tenemos formatos propietarios de aplicaciones, como iDoc.
• Tenemos formatos propios (texto plano, .xml, etc.). Es aquí donde más proble-
mas podemos tener, porque este tipo de formatos están definidos en función de
una serie de especificaciones que no siempre son conocidas.
309
Se ha evolucionado mucho con la inclusión del .xml, se ha humanizado mucho

la forma de transmitir la información, hasta el punto que, pese a no tener porque
entenderse un fichero .xml, se hace legible. El texto plano (usado muchísimo
en los procesos de traspaso de información entre sistemas, sobre todo los más
antiguos), en función de su estructura, es totalmente ilegible. Aún así, su uso
está justificado porque es rápido de procesar y, en ocasiones, esta velocidad es
indispensable.
Problemas:
• Una cantidad enorme de estándares y variaciones. Suponen muchos problemas

de mantenimiento en la vida del aplicativo.
• El mapeo entre los distintos formatos, no siempre es trivial y completo. Por ejem-
plo, es difícil convertir una estructura arbórea como son los .xml en un fichero de
texto plano, intentado trasladar esa relación jerárquica.
Solución:
• Cuantos menos tipos diferentes se usen, mejor.
• Se ha de documentar.
• Existen herramientas que se pueden usar para realizar mapeos y nos facilitan
enormemente la labor.
• Problemáticas en codificación. Esta problemática se produce sobre todo cuan-

do se utilizan sistemas con sistemas operativos diferentes, o hardware diferente.
Puesto que cada sistema tiene un sistema de codificación, impacta directamente
en la manera de enviar y recibir los mensajes de una máquina a otra. Por ejemplo,
cuando intentamos integrar con un sistema que tiene AS/400, éste utiliza la co-
dificación ECBDIC, de forma que si mandamos un fichero desde nuestro sistema
Windows en ASCII, no entenderá nada. Para ello, se ha de asegurar cual será el for-
mato de entrada o de salida y realizar una tarea de conversión para poder entender
y ser entendido.
Otro problema muy común que se solventa de la misma forma se da entre sistemas
Windows y Unix, donde la forma de representar el salto de línea en los ficheros de
texto es diferente, ocasionando que los ficheros no sean bien formateados al mos-
trarse por pantalla o ser leídos por un proceso.
310
• Problemática en diferencias en la estructura. Normalmente, los mensajes que

se transmiten tienen una estructura que ha de ser entendida por los dos sistemas
si quieren que la información sea procesada correctamente. Como comentamos
antes, en los ficheros de tipo .xml, tenemos una representación arbórea de la infor-
mación que la hace más o menos legible. Pero si la forma en que se distribuyen los
hijos y los padres no es entendida por los dos sistemas, no habrá nada que hacer,
el mensaje no podrá ser entendido. Por ejemplo, si el sistema receptor espera una
estructura de tipo:
<hijo>
<nombre>Pedro</nombre>
<apellido>…</apellidos>
</hijo>
Y recibe:
<hijo>
<name>Pedro</name>
<apellido>…</apellidos>
</hijo>
El sistema receptor no será capaz de entender la información que le están intentan-

do enviar. Por eso, es importante ponerse de acuerdo en las especificaciones de la
estructura de los mensajes y evitar este tipo de problemas. Aún así, si los mensajes
se tornan muy complejos, es una tarea ardua que no siempre se libra de errores.
• Problemática en diferencia de containers. Esta problemática se da cuando tene-

mos dos tipos de container diferentes, como por ejemplo un fichero con formato
.xml y uno con texto plano. Ambos containers estructuran la información de forma
diferente: en el caso del .xml es estándar, en el caso del texto plano nos podemos
encontrar mil variedades, cada cual más creativas.
311
• Problema de diferencia de cifrados. Esta problemática se da cuando los sistemas

cifran la información con algoritmos diferentes. Esto pasa por incorporar soporte
para ese cifrado en el receptor o cifrar de acorde a lo que soporte el receptor desde
el emisor.
• Problemas de mantenimiento. Estamos integrando sistemas que no tienen que

ver nada el uno con el otro y que, en muchas ocasiones, las nuevas versiones de las
aplicaciones pueden cambiar cosas que afectan directamente toda la infraestructu-
ra creada para integrar los diferentes sistemas. Imaginemos el ejemplo del sistema
anterior, donde teníamos dos aplicaciones: una con salida de información en un
fichero de texto plano y la otra con un web service para aceptar entrada de infor-
mación. Si nosotros generamos la aplicación, ésta es totalmente dependiente del
formato del fichero y de la estructura de mensaje del web service. Si alguna de las
dos cambiara, alguna de sus especificaciones afectaría directamente al aplicativo
que con seguridad dejaría de funcionar. Claro está, cambiamos el aplicativo y todo
a funcionar de nuevo; si estamos integrando cincuenta aplicaciones diferentes, el
caos puede ser considerable.
• Problemas monitorización. Por norma general, las herramientas de integración

disponen de sus propios sistemas de monitorización para dejar constancia o co-
municarse con otros procesos de lo que sucede durante el proceso de integración.
Alguno de los sistemas que suelen usar las herramientas son:
• Fichero logs: ficheros donde el aplicativo va dejando una traza en la actividad

realizada para su consulta en caso de querer verificar algo o comprobar la causa
de un error.
• Consola: aplicativo que en ocasiones se distribuye con la herramienta de inte-

gración o se desarrolla para mostrar la actividad del sistema de integración. Al
final, muchas de estas herramientas tipo consola permiten un acceso a los logs
de una forma más controlada, añadiendo una capa gráfica.
Pese a que son problemas que tenemos que tener en cuenta e intentar mitigar al
máximo en un proyecto de este tipo, son fácilmente mitigables si se recurre a un
buen diseño del sistema de integración.
Problemas:
• Cada herramienta tiene su monitorización.
• No es trivial detectar y resolver problemas con este tipo de herramientas.
• Herramientas como los log son reactivos: si no son consultados, no se sabe si ha

sucedido algo.
312
Solución:
• Intentar centralizar la integración en una única herramienta para que así sólo
exista un sistema de monitorización.
• Realizar pruebas de estrés y detección de errores habitualmente.
• Intentar buscar herramientas proactivas, que provean de sistemas de alarma que

nos ayuden a anticipar un problema.
31.5. Herramientas de integracción ETL

Dentro de las herramientas de integración, encontramos herramientas ETL (Extract,
Transform and Load) que, como sus siglas indican, son herramientas que se dedican a ex-
traer, transformar y cargar. Éste es el proceso habitual que se realiza en las organizaciones
cuando se quiere integrar una herramienta con otra, el proceso en cada una de sus etapas
es el detallado a continuación.
31.5.1. Extracción
En esta primera parte del proceso, se realiza la extracción de los datos desde del sistema
origen. La práctica más habitual es que los proyectos de almacenamiento de datos conso-
liden datos de diferentes fuentes de origen.
El problema que se ha de solucionar en esta primera etapa es combinar información de

sistemas de origen diferentes, ya que está organizada de forma distinta y probablemente
el formato tampoco sea el mismo. Los formatos más comunes de las fuentes suelen ser
bases de datos relacionales o ficheros de texto plano, pero la diversidad de formatos es
enorme, lo que puede complicar esta etapa. Por tanto, en lo primero es convertir la infor-
mación en un formato que nos permita su posterior transformación.
En esta etapa también se analizan los datos para comprobar si cumplen con las especifi-
caciones de entrada. De esta forma, si la información no es lo que se esperaba, se rechaza.
Por último, hay que tener en cuenta el volumen de datos a extraer. Si el volumen es muy
grande, la tarea puede ser muy pesada y saturar la máquina durante el proceso. Lo que
habitualmente se hace para reducir el impacto de un proceso tan pesado es programar
este tipo de tareas en horas de muy poca actividad, reduciendo los efectos negativos sobre
el sistema.
313
31.5.2. Transformación
En la etapa de transformación de un proceso de ETL, se aplican una serie de reglas de
negocio o funciones sobre los datos extraídos, para convertirlos en datos que serán car-
gados en el sistema destino. Algunas fuentes de datos requerirán alguna pequeña mani-
pulación. En ocasiones, puede ser necesario aplicar algunas de las siguientes transforma-
ciones:
• Filtrar las columnas a cargar, eliminando las que no cumplan con lo esperado o
sean nulas.
• Traducir códigos: por ejemplo, si la fuente almacena una “H” para hombre y “M”
para mujer pero el destino tiene que guardar “1” para hombre y “2” para mujer.
• Codificar valores (por ejemplo, convertir hombre en “H” o Sr en “1”).
• Obtener nuevos valores: éstos pueden ser de tipo numérico o concatenaciones de

varios campos en uno.
• Cruzar datos de múltiples fuentes.
• Calcular totales de múltiples filas de datos (por ejemplo, ventas totales de cada
región).
• Interpretar y dividir una columna en varias (por ejemplo, que en la columna venga
una dirección completa y queramos separar los elementos que conforman la direc-
ción, calle, número, etc.).
• La aplicación de validación de datos con la consiguiente aplicación de reglas que

indiquen a nuestro sistema como actuar en función del resultado.
31.5.3. Carga
En esta etapa toda la información que ha sido extraída y, posteriormente, transformada
se carga en el sistema destino. En función de las necesidades de la organización, este
proceso tiene multitud de posibilidades de acción, como la inserción borrando la infor-
mación anterior o la actualización de la información conservando un histórico. La etapa
de carga interactúa directamente sobre el sistema de base de datos del sistema destino.
Cuando se realice cualquier operación, se aplicarán todas las restricciones y triggers que
se hayan definido en ésta. Estas restricciones y triggers contribuyen a que se garantice la
integridad de los datos en el proceso ETL, así que se deben tener en cuenta a la hora de
plantear todo el proceso.
314

• Arquitectura de sistemas: cómo se estructura por capas la tecnología y da apoyo a

nuestros procesos de negocio:
• La capa de negocio.
• La capa de aplicaciones.
• La capa de arquitectura.
• La capa de hardware.
• Integración de sistemas: proceso por el cual se realizan proyectos con el fin de

comunicar nuestros sistemas, para dar soporte a algún tipo de proceso de negocio
soportado por varios de ellos.
• Patrones básicos de integración: ofrecen una pequeña guía de cómo poder articu-
lar las comunicaciones entre diferentes sistemas.
• One way.
• Request/Response.
• Publish/Subscribe.
• Problemáticas de integración: los principales elementos que intervienen en un

proyecto de integración y los problemas que pueden surgir durante el proceso:
• Seguridad.
• Canal.
• Formato.
• Container.
• Encriptación.
• Codificación.
• Monitorización.
• Gestión de errores.
315
• Herramientas ETL: herramientas de integración que, a través de un proceso de

extracción, transformación y carga, pueden realizar la integración de diferentes
fuentes de datos en una sola:
• Extracción: etapa en la que se extraen los datos de las fuentes de datos origen.
• Transformación: etapa en la que la información es tratada en función de las dife-

rentes reglas de negocio.
• Carga: etapa donde la información finalmente se consolida dentro del sistema

destino.
Dato importante
El canal de comunicación, normalmente, es la primera elección al emprender un

proyecto de integración; es importante, puesto que sustentará todo el intercambio
de información y, si éste no cumple con ciertas propiedades, será imposible contro-
lar errores o monitorizar.
316
32. Open Source

“Un software libre debe garantizar las siguientes libertades: la de
usar el programa con cualquier propósito; estudiarlo y modificarlo;
distribuirlo; y de mejorar el programa y hacer públicas las mejoras
al resto de la comunidad, de modo que ésta salga beneficiada.”
32.1. Antecedentes
A mediados de los años sesenta, el software no tenía entidad propia, se consideraba como
un añadido del hardware, que por esa época consistía en grandes máquinas a las que sólo
se tenía acceso desde el ámbito militar, académico y las grandes empresas. Al ser conside-
rado como un añadido, los desarrolladores compartían libremente sus programas; sobre
todo era muy común que este comportamiento se produjera en el ámbito académico y
empresarial.
Con el crecimiento de la industria y el boom que se produjo los años ochenta, este com-
portamiento empezó a cambiar y los ordenadores comenzaron a utilizar sistemas operati-
vos propietarios que obligaban a lo usuario a aceptar condiciones que impedían cualquier
modificación del sistema operativo. Las consecuencias de esto se notaron rápidamente;
cuando alguno de estos softwares tenía un error, los usuarios sólo tenían la posibilidad
de comunicarlo a la empresa propietaria para que lo solventase, al contrario que lo que se
hacía anteriormente (si el usuario sabía solventar el problema, lo hacía gratis y lo ponía a
disposición de la comunidad).
En 1984, R. Stallman considerado el padre del Open Source, comenzó su proyecto GNU, y
en 1985 creó la Free Software Fundation. Stallman acuñó el término de software libre junto
con el de copyleft, que regulaba de alguna forma los derechos de los usuarios y restringía
la posible apropiación del software. De esta forma, se definía que un software es libre
cuando se garantizan las siguientes libertades:
• La libertad de usar el programa con cualquier propósito.
• La libertad de estudiar cómo funciona el programa y modificarlo según necesida-

des.
• La libertad de distribuir copias del programa con las que poder ayudar a los demás.
• La libertad de mejorar el programa y hacer públicas las mejoras al resto de la comu-

nidad, de modo que ésta salga beneficiada.
317
Como tal, se estableció la siguiente misión para el movimiento:
“Open Source es un método de desarrollo que utiliza el poder de la revisión distribuida y

la transparencia de procesos. La promesa de Open Source es mejor calidad, mejor dispo-
nibilidad, más flexibilidad, costes más bajos y el final de bloque de la venta predadoras”.
Opensource.org
De la misión, se puede extrapolar que lo que hace poderoso a este movimiento es la ca-
pacidad de aportación y trabajo de una comunidad de gente que sin ningún tipo de afán
económico aporta y comparte sus conocimientos con el resto. Esto ha hecho que poda-
mos encontrar que aplicativos de software libre estén de los primeros en listas de los
más usados en el mundo empresarial. Por ejemplo, Apache, que cuadriplica en uso a su
competidor más directo y de pago, el Internet Information Server. El software libre es una
potente herramienta a tener en cuenta.
32.2. Tipos de licencias Open Source

Puede resultar difícil entender qué se puede hacer exactamente con el software: ¿sólo se
puede usar?, ¿se puede modificar?, ¿si se modifica, que se ha de hacer luego?, a menudo
surgen estas dudas a causa de la cantidad de tipos de licencias que existen y cómo éstas
articulan los derechos de los usuarios.
Para empezar, veremos la diferencia entre varios términos que es importante entender
cuando nos movemos por el mundo de los derechos sobre contenidos software:
• Licencia: contrato entre el usuario y el desarrollador de un software, el cual está

sometido a una serie de derechos y propiedad intelectual. Ésta define exhausti-
vamente los derechos y obligaciones que ambas partes contraen. Es el dueño de
los derechos de explotación del software (se define así porque el desarrollador no
siempre tiene los derechos, puede haber cedido los derechos de explotación a un
tercero) el que decide el tipo de licencia.
• Patente: conjunto de derechos exclusivos y garantizados por un gobierno o autori-

dad al inventor de un nuevo producto, ya sea material o inmaterial, que sea suscep-
tible de ser explotado industrialmente para bien del solicitante durante un periodo
de tiempo limitado que se estipula en función de determinados factores.
• Derecho de autor o copyright: forma de protección que proporciona las leyes vi-
gentes en muchos países para los creadores de obras originales, incluyendo obras
artísticas e intelectuales, tanto aquéllas que han sido publicadas como las que es-
tán pendientes de publicar.
318
• Software de código abierto. Han de cumplir lo siguiente:
• Son de distribución libre.
• Han de incluir el código fuente, permitiendo la modificación y acciones deriva-

das en las mismas condiciones que el software original.
• Integridad del código fuente del autor, pudiendo requerir que los trabajos deri-
vados tengan distinto nombre o versión.
• Sin uso restringido a ninguna actividad.
• La licencia no debe ser específica para un producto determinado.
• La licencia no debe poner restricciones a otro producto que se distribuya junto

con el software licenciado.
• La licencia deber ser tecnológicamente neutral.
• Software de dominio público: aquél que no está protegido con copyright.
• Software con copyleft: software libre, cuyos términos de distribución no permiten

a los redistribuidos agregar ninguna restricción adicional cuando es redistribuido
o modificado.
• Software semilibre: aquél que no es libre, pero viene con la autorización de usarse,
copiarse, distribuirse y modificarse sólo para particulares y sin fines lucrativos.
• Shareware: aquél que se puede distribuir gratuitamente, pero se ha de pagar licen-

cia si se hace un uso continuado de él.
• Freeware: permite la distribución y el uso gratuito, pero no su modificación.
• Software privativo: aquél que su uso, redistribución o modificación están prohibi-

dos o necesitan de una autorización, normalmente bajo pago.
• Software comercial: aquél que desarrolla una empresa que quiere conseguir algún
tipo de remuneración por su uso.
319
Los tipos de licencia de software Open Source y sus características son:
• Licencias de software libres permisivas. Se pueden usar, distribuir y modificar sin

que se tenga obligación de protección alguna. Este tipo de licencias permiten a los
usuarios hacer lo que más les convenga con el software. No existe ninguna obliga-
ción con el uso del software libre que se le facilite: pueden reutilizarse, modificarse,
darse abiertos o cerrados al usuario. Las más populares son:
• Academic Free License v.1.2.
• Apache Software License v.1.1.
• Artistic License v.2.0.
• Attribucion Assurance License.
• BSD License.
• MIT License.
• University of Illinois/NCSA Open Source License.
• W3C Software Notice and License.
• Zope Public License v.2.0.
• Open LDAP License v.2.7.
• Perl License.
• Academic Free License v.3.0.
• Python License v.2.1.
• PHP License v.3.0.
• Q Public License v.1.0.
320
• Licencias de software libre fuertes. También llamadas “con copyleft fuerte”. Obli-
gan a que las obras derivadas o modificaciones que se realicen del original tengan
licencia bajo los mismos términos y condiciones que la licencia de origen. Son
más restrictivas en su uso. Por ejemplo, si se usa una de éstas como base para un
desarrollo, todo lo que se haga deberá ser software libre y nunca se podrá realiza
un software cerrado. Las más conocidas son:
• Common Public License v.1.0.
• GNU General Public License v.2.0.
• GNU General Public License v.3.0.
• Eclipse Public License.
• eCos License v.2.0.
• Sleepycat Software Product License.
• Affero License v.1.0.
• Affero License v.2.0.
• OpenSSL License.
• Licencias de software libre débiles. Tienen un copyleft suave, contienen una cláu-
sula que obliga a que las modificaciones que se realicen al software original se
licencien bajo los mismos términos de la original, pero las obras que se deriven
del original se puedan licenciar bajo otras condiciones distintas. Ésta nos permite
enlazar productos libres con privativos. Las más conocidas son:
• GNU Lesser General Public License v.2.1.
• Mozilla Public License.
• Open Source License.
• Apple Source License v.2.0.
• CDDL.
• EUPL.
321
32.3. Open Source en las empresas

El mundo empresarial ha sido muy reacio al Open Source durante mucho tiempo, por la
dificultad de encontrar trabajadores con perfiles cualificados o por el miedo a no conse-
guir soporte de terceros cuando aparecieran los problemas.
Algo muy común al usar algún tipo de software Open Source por parte de los directivos
era preguntase: ¿qué pasa si desaparece la empresa/grupo que realiza el software? Ésta
claro que esto puede ocurrir, pero con el tiempo se ha demostrado que esto no sólo pasa
en el Open Source. Por ejemplo, Microsoft, en plena fiebre Java, sacó su Visula J++, que
descontinuó cuando perdió el interés en el lenguaje, dejando sin soporte a muchas empre-
sas que apostaron por este nuevo entorno. En la actualidad, son muchas las empresas que
utilizan software Open Source y también se ha extendido al ámbito de los particulares,
que con el tiempo se han encontrado con software de la misma calidad que los propieta-
rios, y gratis.
Algunos de los más conocidos son:
• Linux (Debian, Suste, etc.).
• Mozilla Firefox.
• Apache.
• Open Office.
• Android.
• Php.
Los grandes han optado por el software libre, lo que le supone grandes ahorros en licen-
cias.
32.4. Ejercicio: Office Vs. Openoffice.org

Tenemos una empresa y queremos implantar una suite ofimática. Estamos pensando en
poner Office, pero cada vez más escuchamos hablar de OpenOffice.org. Quisiéramos un
informe comparativo haciendo énfasis en el coste, soporte, funcionalidad, compatibilidad
de formatos, difusión en el mercado y una opinión del usuario.
322
32.4.1. Solución
Costes 119€ 1 usuario 1 Pc 0€
Soporte gratuito de Microsoft, Soporte a través de la web

Soporte ya sea a través de su web o y la comunidad de Ope-
teléfonos habilitados. nOffice.org.
La versión de 119€ dispone Text Document (Word),

de Word, Excel, PowerPoint y Spreadsheet (Excel),
Funcionalidad OneNote. Si queremos Access Drawing, Reviews, Presen-
y Outlook se ha de comprar la tation (PowerPoint) y Data-
versión que cuesta 499€. base (Access).
Office tiene como premisa OpenOffice.org, a parte de

mantener compatibilidad ha- los suyos propios y gracias
cia atrás. Pese a haber cam- a su carácter abierto y una
biado todos sus formatos en comunidad que amplía el
2007, sigue soportando las proyecto, soporta los más
versiones anteriores, así que variopintos formatos. En
a los actuales (docx, pptx, cuanto a compatibilidad con
Compati- xlsx, etc.) hay que sumar to- Office, soporta la gran ma-
bilidad de dos los formatos de versiones yoría de formatos, pero con
formatos anteriores y muchos tipos de limitaciones de formatos,
formatos de carácter más bá- tipos de letras o problemas
sicos y que se remontan a an- en la ejecución de scripts.
tes de que existiera la propia Sobre todo, si son de las
Office. Como curiosidad, no versiones más nuevas de
es compatible con los forma- Office.
tos de OpenOffice.org.
Se estima que tiene una cuota Se estima que tiene una

Difusión en de mercado cercana al 80%. cuota de mercado cercana
el mercado al 20%.
323
Al ser el producto mayoritario El hecho de que la cuota de

desde hace mucho tiempo, OpenOffice.org aumente in-
la gente tiende a conocerlo dica que esta situación se
más. Pese a que raramente produce más. Parece algo
se produce que se pase de más traumático pasar de
Gestión del OpenOffice.org a Office, no Office a OpenOffice.org, ya
cambio para por calidad ni funcionalidades sea por que pese a ser simi-
usuarios sino porque es más compli- lares en funcionalidades no
cado pasar de algo gratuito son del todo iguales y eso
a algo de pago, creo que en lleva a la confusión.
los casos que se da el cambio
no es muy traumático en esa
dirección.
Tabla 1. Comparativa Office y OpenOffice.org

32.4.2. Conclusiones personales

Personalmente, he trabajado con las dos herramientas y pese a que me parece una inicia-
tiva admirable la de OpenOffice.org y creo que no va por mal camino, mi opinión es que
(de momento) le falta más tiempo y esfuerzo para posicionarse donde está la Office de
Microsoft. Es una carrera contra un gigante que, pese a que a veces hace las cosas mal,
suele bordar las segundas oportunidades. Creo que si actualmente está consiguiendo más
cuota de mercado es porque la situación económica está obligando a muchas empresas y
organismos públicos a replantearse sus costes de licencias y a la tendencia que se expe-
rimenta y extiende en muchos ámbitos de que lo Open Source está de moda; pese a que
soy un gran defensor de Open Source, considero que esto es un error y cada cosa tiene su
sitio y su momento.
324
Para mí, el rendimiento, las funcionalidades y el look and feel de las aplicaciones de Office
son superiores a las de OpenOffice.org. Por no comentar que el hecho de tener detrás una
empresa como Microsoft desde 1984, empujando su suite y sacando versión tras versión
con el afán de no dejar posicionarse a nadie más en ese hueco, se nota sobradamente en
un producto que ha ganado versión tras versión y que, pese a los cambios de look en las
últimas versiones (que en algún momento han podido levantar ampollas, sobre todo en
aquellos usuarios menos propensos al cambio), hoy en día sigue siendo el líder.
Dicho esto, creo que OpenOffice.org está haciendo algo mejor que Office: abrirse a más
sistemas operativos. Pese a que las plataformas Linux puedan ser minoritarias, van en
aumento y, ciertamente, si quieres una suite de lo mejor que te puedes encontrar en dicha
plataforma es OpenOffice.org. Ésta está disponible para Linux, Windows y Mac, mientras
que Office está disponible para Windows y Mac. El caso de Office en Mac es muy curioso
porque, pese a tener el mismo nombre, las versiones Mac y Windows son algo diferentes
y se nota en gran medida en la interfaz del usuario, donde la de Mac está mucho más
cuidada.
Me gustaría aclarar que, pese a que considero mejor solución a Microsoft, no dudaría ni
un minuto en poner OpenOffice.org en una máquina para una persona que necesitase
una suite ofimática. Creo que le haría un servicio muy similar y que tarde o temprano
se habituaría a usarla. Por el contrario, si esa persona fuera a hacer uso intensivo de los
formatos de Office a causa, por ejemplo, de un cliente que me envía la información en
formatos de la suite de Microsoft, sin duda utilizaría Office y me evitaría más de un dolor
de cabeza a la hora de exportar e importar ficheros de una solución a otra.
Otro motivo por el que pondría Office sería si el usuario usase funcionalidades algo más
específicas, como macros en una hoja de cálculo o base de datos, no sólo porque me pare-
ce mejor en la gestión de scripts que OpenOffice.org, sino porque si ese usuario se fuera,
sería mucho más fácil encontrar a alguien que conociera o entendiera el trabajo hecho por
el primer usuario.
Para finalizar, ambas soluciones me parecen buenas y tienen sus pros y sus contras, pero
se notan los años de ventaja que Office le lleva a OpenOffice.org y creo que no va a ser
fácil el camino de este último.
325

• Introducción al Open Source:
• Aplicaciones a medida.
• Aplicaciones cerradas o propietarias.
• Aplicaciones abiertas o de código abierto.
• Tendencias en aplicaciones:
• Aplicaciones Open Source.
• Aplicaciones móviles.
• Aplicaciones cloud computing.
Dato importante
“Open Source es un método de desarrollo que utiliza el poder de la revisión distri-

buida y la transparencia de procesos. La promesa de Open Source es mejor calidad,
mejor disponibilidad, más flexibilidad, costes más bajos y el final de bloque de la
venta predadoras”.
Opensource.org
326
Bibliografía
Publicaciones
• BENIOFF, M y ADLER, C.Behind the Cloud: The Untold Story of How Salesforce.
com Went from Idea to Billion-Dollar Company-and Revolutionized an Industry,
2009.
• RIBAS LEQUERIA, J. Web services (guías prácticas). Anaya multimedia, 2003.
• SOA Governance: High-impact Strategies - What You Need to Know: Definitions,

Adoptions, Impact, Benefits, Maturity, Vendors.
• VOLONINO, L. and ROBINSON, S. Principles and Practices of Information Secu-

rity. Pearson Prentice Hall, 2004.
• CAMPAGNA, R, IYER, S, KRISHNAN, A and BAUHAUS, M. Mobile Device Secu-

rity For Dummies (Math & Science). Agosto, 2011.
• FRIED, Stephen. Mobile Device Security: A Comprehensive Guide to Securing

Your Information in a Moving World. Junio, 2010.
• WESCOTT, C. , PIZARRO, M., & SCHIAVO-CAMPO, S. (2001). The Role Of Infor-

mation And Communication Technology In Improving Public Administration. (p.
31). Manila: ADB.
• WASSENAAR, A. (2000). E-Govermental Value Chain Models. (pp. 289-293). Lon-

don, Greenwich: DEXA 2000, IEEE Press.
• ARMENDÁRIZ, L.M. Historia de la computación.
• Patterns and Best Practices for Enterprise Integration.
Legislación
• LOPD
https://www.boe.es/buscar/pdf/1999/BOE-A-1999-23750-consolidado.pdf
327
Enlaces de interés
• http://www.whatiscloud.com/
• http://searchcloudcomputing.techtarget.com/definition/cloud-computing
• http://www.soaprinciples.com/
• http://h17007.www1.hp.com/us/en/converged-infrastructure/
• http://www.microsoft.com/latam/technet/infraestructura/optimizacion.mspx
• what is green it
http://energypriorities.com/entries/2007/06/what_is_green_it_data_centers.php
• http://rdimas.obolog.com/criterios-seleccion-tecnologias-informacion-332016
• http://www.gestiopolis.com/administracion-estrategia/criterios-para-la-seleccion-
de-software-empresarial.htm
• http://www.infospyware.com/articulos/que-son-los-malwares/
• h t t p : // t e c n o l o g i a . e l p a i s . c o m / t e c n o l o g i a /2 0 0 9 / 0 8 / 0 6 /a c t u a l i -
dad/1249549262_850215.html
• http://www.computerweekly.com/news/2240162149/Saudi-Aramco-oil-firm-
claims-to-be-over-cyber-attack
• http://www.abc.es/20120606/medios-redes/abci-linkedin-ataque-contrase-
nas-201206061705.html
• http://www.infoworld.com/t/misadventures/employee-incompetence-hackers-
best-friend-819
• http://www.infoworld.com/d/adventures-in-it/why-trouble-employees-pas-
swords-576
• http://unpan1.un.org/intradoc/groups/public/documents/APCITY/
UNPAN015120.pdf
328
• APLICACIONES PARA MÓVILES:
http://www.gartner.com/it/page.jsp?id=1230413
• BREVE HISTORIA DE LA INFORMÁTICA:
http://www.monografias.com/trabajos10/recped/recped.shtml
• C4ISR:
http://riunet.upv.es/bitstream/handle/10251/6067/tesisUPV3119.pdf
• CMMI:
http://albinogoncalves.files.wordpress.com/2011/03/una-introduccion-a-cmmi.pdf
http://www.sei.cmu.edu/cmmi/
http://www.sei.cmu.edu/library/assets/cmmi-dev-v12-spanish.pdf
• DEBIAN:
http://www.debian.org/index.es.html
• INTEGRACIÓN Y CALIDAD:
http://integracionycalidad.blogspot.com.es/2008/04/elegir-una-herramienta-de-
integracin-de.html
• LENGUAJES DE PROGRAMACIÓN:
http://www.lenguajes-de-programacion.com/
http://www.monografias.com/trabajos/lengprog/lengprog.shtml
• MANIFIESTO ÁGIL:
http://www.agilemanifesto.org/
• METODOLOGÍAS ÁGILES:
• http://www.javiergarzas.com/metodologias-agiles
http://www.eumed.net/libros-gratis/2009c/584/Metodologias%20tradiciona-
les%20y%20metodologias%20agiles.htm
http://www.proyectosagiles.org/que-es-scrum
329
• MÉTRICA V3:
http://administracionelectronica.gob.es/?_nfpb=true&_pageLabel=P600859012742
01580632&langPae=es
• MODELOS DE SISTEMAS:
http://www.dia.eui.upm.es/asignatu/Sis_dis/Transparencias/Cap2ModelosArqui-
tectonicos.pdf
• OPEN SOURCE:
http://www.dataprix.com/blogs/respinosamilla/herramientas-etl-que-son-para-
que-valen-productos-mas-conocidos-etl-s-open-sour
http://emekaeme.wordpress.com/2008/04/27/modelos-de-negocio-open-source-
conversacion-con-john-powell-ceo-de-alfresco/
http://newsroom.accenture.com/article_display.cfm?article_id=5045
• OPENOFFICE:
http://blog.open-office.es/index.php/inicio/2011/03/04/microsoft-office-2010-vs-
openoffice-org-3-3
• SCRUM:
http://www.mountaingoatsoftware.com/scrum
http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-
trincheras.pdf
• SISTEMA OPERATIVO GNU:
http://www.gnu.org/philosophy/categories.es.html
• SOFTWARE:
http://www.monografias.com/trabajos60/metodologias-desarrollo-software/meto-
dologias-desarrollo-software.shtml
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
330
Lecturas recomendadas
• VIRTUALIZATION FOR DUMMIES.
https://ssl.www8.hp.com/de/de/pdf/virtuallisation_tcm_144_1147500.pdf
• http://noticias.juridicas.com/base_datos/Admin/l34-2002.html
• Stopping insider attacks: how organizations can protect their sensitive informa-
tion.
http://www-935.ibm.com/services/in/cio/pdf/gov_wp_gts_stopping.pdf
• Guía de Respuesta Jurídica a los ataques contra la Seguridad de la información
https://es.scribd.com/document/47534701/Guia-sobre-la-respuesta-juridica-a-los-
ataques-contra-la-Seguridad-de-la-Informacion
• http://www.guardian.co.uk/technology/gamesblog/2011/apr/27/playstation-net-
work-hack-sony
• McCREARY, L. What was Privacy? Harvard Business Review. October, 2008
http://cb.hbsp.harvard.edu/cb/web/product_detail.seam?E=72935&R=R0810J-PDF-
ENG&conversationId=219318
• Privacidad en Facebook
http://onsoftware.softonic.com/privacidad-facebook
• http://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf
• http://searchmobilecomputing.techtarget.com/tip/Mobile-policies-Secure-your-
corporate-data-with-acceptable-use-policies
• http://mobiledevices.about.com/od/kindattentiondevelopers/f/Mobile-Device-
Security-Policy-FAQs-for-Enterprise.htm
• https://www.ccn-cert.cni.es/herramientas-de-ciberseguridad/ear-pilar.html
• www.ccn.cni.es/
• http://searchdatacenter.techtarget.com/es/consejo/Estrategias-de-Backup-de-da-
tos-Migracion-de-cinta-a-disco
331
Glosario de términos
ACTIVO: componente o funcionalidad de un sistema de información susceptible de ser

atacado deliberada o accidentalmente con consecuencias para la organización. Incluye:
información, datos, servicios, aplicaciones (software), equipos (hardware), comunicacio-
nes, recursos administrativos, recursos físicos y recursos humanos.
ADWARE: software que inyecta publicidad en nuestro sistema.
AMENAZA: causa potencial de un incidente no deseado, el cual puede causar el daño a

un sistema o la organización.
ANÁLISIS DE RIESGOS: utilización sistemática de la información disponible para iden-

tificar peligros y estimar los riesgos.
API: Interfaces Relacionadas de Aplicaciones.
APPLETS: pequeños programas realizados en Java que se pueden incluir dentro de otros
entornos como páginas web y reutilizar.
ASTERISK: software Open Source que permite la creación de centralitas telefónicas, so-
porta los principales sistemas de VoIP y muchos de la electrónica para la comunicación
analógica.
AUTENTICIDAD: propiedad o característica consistente en que una entidad es quien

dice ser o bien que garantiza la fuente de la que proceden los datos.
BACKUP: práctica por la cual debiéremos proteger nuestros datos y crear copias de se-
guridad.
BACKUP A DISCO: realizar una copia de seguridad a un dispositivo de tipo disco duro
de almacenamiento.
BACKUP A CINTA: realizar una copia de seguridad a un dispositivo de tipo Magnetóp-

tico.
BASIC: lenguaje de programación.
BIGDATA: tendencia de gestión de datos masivos.
332
BLADES: servidores ultra densos, que ocupan menos espacio y funcionan en un bastidor
que les permite compartir recursos como alimentación, refrigeración o gestión.
BPM (BUSINESS PROCESS MANAGEMENT): sistema que permite su automatización a

base de la modelización de los procesos de unidades de negocio. El sistema está formado
por varios módulos que cubren todas las necesidades a la hora de traspasar los procesos.
BOOT: sector de arranque de un ordenador.
BYOD: Bring Your Own Device tendencia que implica que el usuario puede utilizar sus
herramientas personales en la empresa.
CATEGORÍA DE UN SISTEMA: es un nivel, dentro de la escala Básica-Media-Alta, con el

que se adjetiva un sistema a fin de seleccionar las medidas de seguridad necesarias para
el mismo. La categoría del sistema recoge la visión holística del conjunto de activos como
un todo armónico, orientado a la prestación de unos servicios.
CICLO DE VIDA: el ciclo de vida del software comprende todas las fases, desde el inicio
cuando se realiza la toma de requerimientos con los usuarios, pasando por el diseño o la
codificación, hasta llegar al momento evolutivo o de mantenimiento.
CLOUD COMPUTING: arquitectura escalable, elástica, orientada a servicios a través de

tecnología web.
CLOUD HIBRIDO: combinación del Cloud público y el Cloud privado
CLOUD PÚBLICO: uso del Cloud Computing en Internet.
CLOUD PRIVADO: aplicación de Cloud Computing dentro del entorno empresarial, de-
trás de nuestro firewall.
CÓDIGO FUENTE: conjunto de instrucciones del programa que están escritas en lengua-
je de programación.
CÓDIGO MALICIOSO: código desarrollado con intención de hacer el mal dentro de los
sistemas.
COMUNICAR EL RIESGO: intercambiar o compartir información del riesgo entre los res-
ponsables del riesgo y otras partes interesadas.
CONFIDENCIALIDAD: propiedad o característica consistente en que la información ni

se pone a disposición, ni se revela a individuos, entidades o procesos no autorizados.
333
CONTROL: las políticas, los procedimientos, las prácticas y las estructuras organizativas
concebidas para mantener los riesgos de seguridad de la información por debajo del nivel
de riesgo asumido. Control es también utilizado como sinónimo de salvaguarda o contra-
medida.
COOKIES: información almacenada para conocer y facilitar nuestros movimientos por

la red.
CREEPER: primer virus de la historia.
DATACENTER: Centro de Datos, donde se almacenan los sistemas.
DEBIAN: distribución del sistema operativo Open Source Linux.
DEDUPLICACIÓN: capacidad para eliminar datos repetidos en un almacenamiento o

backup.
DISPONIBILIDAD: propiedad o característica de los activos consistente en que las enti-

dades o procesos autorizados tienen acceso a los mismos cuando lo requieren.
DDoS: ataque por Denegación de Servicio desde sitios distribuidos.
EC2: Elastic Cloud Computing, una oferta de Amazon.
EFECTO DOS MIL: en el inicio de la creación de software, los recursos de las maquinas
eran muy limitados y se tendía a optimizar al máximo el código, de forma que éste hiciera
el menor uso posible de dichos recursos. Como consecuencia, las forma de almacenar los
años en una fecha sólo tenía en cuenta las dos últimas cifras de la fecha, lo cual haría que,
una vez llegado al 31 de diciembre de 1999, se pasase al 01 de 1900, con el consiguiente
problema.
EMV: Europay, MasterCard, VISA, protocolo de seguridad para obligar a la utilización de

código pin para los pagos.
ENTALPIA: relación entre la temperatura y la humedad.
ERP: Enterprise Resource Planning, software de gestión que sirve para manejar distintas
áreas de la empresa.
EVALUACIÓN DE RIESGOS: proceso de comparar el riesgo estimado contra un criterio

de riesgo dado con el objeto de determinar la importancia del riesgo.
EVITAR EL RIESGO: decisión de no involucrarse en una situación de riesgo, o posibles

acciones que podrían desembocar en situaciones de riesgo.
334
ETHERNET: canal de comunicación entre máquinas.
FIBER CHANEL: canal de comunicación entre un servidor y un dispositivo de almacena-

miento con unos protocolos específicos basados en fibra óptica.
FIREWALL: muro de protección que impide el acceso a los sistemas de un ordenador o

una empresa, puede ser un dispositivo de software o un entorno de hardware que nos pue-
da permitir establecer políticas de bloqueo y de protección de nuestros sistemas.
GESTIÓN DE INCIDENTES: plan de acción para atender a las incidencias que se den.
Además de resolverlas, debe incorporar medidas de desempeño que permitan conocer
la calidad del sistema de protección y detectar tendencias antes de que se conviertan en
grandes problemas.
GESTIÓN DE RIESGOS: actividades coordinadas para dirigir y controlar una organiza-

ción con respecto a los riesgos.
GOOGLE ADSENSE: herramienta de Google de gestión de publicidad.
GOOGLE ADWORDS: herramienta de Google de gestión de publicidad.
GPL (GENERAL PUBLIC LICENSE): creada en 1989 por la Free Software Fundation, está
principalmente orientada a salvaguardar la libre distribución y modificación de las apli-
caciones de código abierto.
HOAX: Rumor.
IDENTIFICAR RIESGOS: proceso para localizar, listar y determinar los atributos de los
elementos del riesgo.
INCIDENTE DE SEGURIDAD: suceso inesperado o no deseado con consecuencias en

detrimento de la seguridad del sistema de información.
INTEGRIDAD: propiedad o característica consistente en que el activo de información no

ha sido alterado de manera no autorizada.
INTÉRPRETE: programa que traduce de lenguaje de alto nivel a lenguaje de máquina de

una computadora. El programa siempre permanece en su forma original (programa fuen-
te) y traduce cuando está en la fase de ejecución instrucción por instrucción.
IMPACTO: el coste para la empresa de un incidente de la escala que sea y que puede o no
ser medido en términos estrictamente financieros (por ejemplo, pérdida de reputación,
implicaciones legales, entre otros).
335
IAAS: infraestructura como servicio que nos permitirá alquilar una infraestructura o pre-
sentarla en modo pago por uso.
INFRAESTRUCTURA CONVERGENTE: estado tecnológico de la empresa en que todos

los componentes de la infraestructura trabajan y funcionan de forma coordinada para
conseguir los máximos ahorros y beneficios.
IPS: software de protección contra intrusos.
ISCSI: tecnología de comunicación que integra el protocolo de acceso al almacenamiento

(SCSI) dentro del protocolo IP.
LENGUAJE DE ALTO NIVEL: lenguaje que se asemeja más al lenguaje humano que a un
lenguaje de máquina o ensamblador. Es más fácil escribir programas en este lenguaje,
pero luego deben ser traducidos por compiladores o intérpretes para que la computadora
los entienda.
LENGUAJE DE BAJO NIVEL: lenguaje de programación cercano al lenguaje de máquina.
LENGUAJE DE MÁQUINA: lenguaje orientado hacia la máquina que está constituida por
varios arreglos de bits. Este lenguaje es fácil de entender por la computadora, pero difícil
para el usuario.
LENGUAJES DE PROGRAMACIÓN: lenguajes especiales que ayudan al usuario a comu-

nicarse con la computadora.
LISTA ROBINSON: lista de exclusión para la publicidad no solicitada.
MALWARE: software malicioso que busca hacer el mal dentro de un sistema, atacarlo o
destruir sus datos.
MEDIDAS DE SEGURIDAD: conjunto de disposiciones encaminadas a protegerse de los

riesgos posibles sobre el sistema de información, con el fin de asegurar sus objetivos de
seguridad. Puede tratarse de medidas de prevención, de disuasión, de protección, de de-
tección y reacción, o de recuperación.
MMS: mensajes multimedia que pueden incluir fotos, video o mayores cantidades de tex-
to.
NFC: Near Field Communication. Sistema de comunicación basado en RFID que nos sir-
ve para establecer una pasarela entre dos dispositivos, como por ejemplo para pagar en
una tienda.
PAAS: plataforma como servicio que nos permitirá alquilar una plataforma de desarrollo
o trabajo y presentarla en modo pago por uso.
336
PASARELA DE PAGO: entorno de pago en el comercio electrónico de manera segura.
PAYPAL: empresa que surgió para facilitar los pagos a través de Internet.
PBX: como se denomina a la electrónica que gestiona una centralita telefónica.
PLAN DE TRATAMIENTO DE RIESGOS: documento de gestión que define las acciones

para reducir, prevenir, transferir o asumir los riesgos de seguridad de la información in-
aceptables e implantar los controles necesarios para proteger la misma.
POLÍTICA DE SEGURIDAD: conjunto de directrices plasmadas en documento escrito,

que rigen la forma en que una organización gestiona y protege la información y los servi-
cios que se consideran críticos.
POPUP: ventana emergente.
PRINCIPIOS BÁSICOS DE SEGURIDAD: fundamentos que deben regir toda acción

orientada a asegurar la información y los servicios.
PROCESO: conjunto organizado de actividades que se llevan a cabo para producir a un

producto o servicio; tiene un principio y fin delimitado, implica recursos y da lugar a un
resultado.
PROCESO DE SEGURIDAD: método que se sigue para alcanzar los objetivos de seguri-
dad de la organización. El proceso se diseña para identificar, medir, gestionar y mantener
bajo control los riesgos a que se enfrenta el sistema en materia de seguridad.
PROGRAMACIÓN PROCEDURAL: paradigma de desarrollo (también llamada progra-

mación imperativa) que se basa en subdividir parte del código en trozos llamados proce-
dimiento, subrutinas o funciones dependiendo de su uso, y que permite la especialización
del código en librerías que facilitan su reutilización o corrección.
PROGRAMACIÓN ORIENTADA A OBJETOS: paradigma de desarrollo más complejo

que la procedural, donde el código se subdivide en los objetos con ciertas propiedades,
que no sólo ofrece los beneficios de la programación procedural, sino que hace que el de-
sarrollo se torne más sencillo, al definir este código como algo más cercano a la realidad
que representa, haciendo que sea más entendible.
PUE: medida de eficiencia energética.
RAE: Real Academia de la Lengua Española.
REDUCCIÓN DEL RIESGO: medidas adoptadas para reducir la probabilidad y/o las con-
secuencias negativas asociadas a un riesgo.
337
REQUISITOS MÍNIMOS DE SEGURIDAD: exigencias necesarias para asegurar la infor-

mación y los servicios.
RETENCIÓN DEL RIESGO: aceptación de la carga asociada a la pérdida introducida por

un riesgo.
RIA (RICH INTERNET APPLICATIONS): aplicaciones web que ofrecen mayores posibi-
lidades de interacción que las antiguas aplicaciones.
RIESGO: estimación del grado de exposición a que una amenaza se materialice sobre uno
o más activos causando daños o perjuicios a la organización.
RFID: Radio Frequency Identification. Sistema de identificación por radiofrecuencia, que

detecta dispositivos de acuerdo a una señal de radio pregrabada.
SaaS: Software as a Service, o cómo adquirir un software para su uso por una persona o
empleado, a través de Internet.
SEGURIDAD DE LAS REDES Y DE LA INFORMACIÓN: la capacidad de las redes o de los

sistemas de información de resistir, con un determinado nivel de confianza, los accidentes
o acciones ilícitas o malintencionadas que comprometan la disponibilidad, autenticidad,
integridad y confidencialidad de los datos almacenados o transmitidos y de los servicios
que dichas redes y sistemas ofrecen o hacen accesibles.
SISTEMA DE GESTIÓN DE LA SEGURIDAD DE LA INFORMACIÓN (SGSI): sistema

de gestión que, basado en el estudio de los riesgos, se establece para crear, implementar,
hacer funcionar, supervisar, revisar, mantener y mejorar la seguridad de la información.
El sistema de gestión incluye la estructura organizativa, las políticas, las actividades de
planificación, las responsabilidades, las prácticas, los procedimientos, los procesos y los
recursos.
SISTEMA DE INFORMACIÓN: conjunto organizado de recursos para que la información

se pueda recoger, almacenar, procesar o tratar, mantener, usar, compartir, distribuir, poner
a disposición, presentar o transmitir.
SMS: mensajes cortos de texto entre móviles.
SNAPSHOT: fotografía en un instante dado de un sistema para poder realizar operacio-

nes con él como realizar un backup o hacer una actualización.
SNIFFER: rastreadores.
SOA: Arquitectura Orientada a Servicios que define la utilización de servicios de software

para dar soporte a los requisitos de negocio.
338
SPOOFING: intento de suplantar la identidad.
SPYWARE: software malicioso que espía nuestros movimientos.
TRANSFERIR EL RIESGO: compartir la carga asociada a la pérdida introducida por un

riesgo.
TRAZABILIDAD: propiedad o característica consistente en que las actuaciones de una

entidad pueden ser imputadas exclusivamente a dicha entidad.
TROYANO: software malicioso que busca ocultarse.
UNIX: Sistema Operativo orientado para su uso en servidores que desarrollaban diferen-
tes fabricantes para optimizar y sacar partido a sus sistemas.
VALORACIÓN DEL RIESGO: proceso completo de análisis y evaluación de riesgos.
VIRTUALIZACIÓN: tecnología que permite la abstracción de los componentes físicos

para su reutilización por diferentes estructuras lógicas.
VIRUS: software malicioso que busca alterar el funcionamiento del sistema.
VOIP: protocolo que permite la comunicación de voz a través de internet, digitalizando la

voz y transmitiéndola a través de la red.
VULNERABILIDAD: una debilidad que puede ser aprovechada por una amenaza.
VPN: red privada virtual que nos permitirá acceder de forma remota a la red corporativa,
trabajando como si estuviéramos dentro de la empresa, atravesando las protecciones del
firewall.
WEB SERVICES: tecnología que facilita el intercambio de información entre diferentes

sistemas que pueden estar alojados en máquinas diferentes, usando distintos lenguajes
de programación, gracias al uso de mensajes estandarizados.
339
CEUPE
Centro Europeo de Postgrado
Web
www.ceupe.com
E-mail
info@ceupe.com

MSIT - A2 - Mod6 - Gestion y Desarrollo de Sistemas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

MSIT - A2 - Mod6 - Gestion y Desarrollo de Sistemas

Cargado por

Copyright:

Formatos disponibles

Módulo

1.1. Criterios racionales

1. Identificando los objetivos de rendimiento necesarios para el correcto funcionamien-

2. Analizando las diferentes alternativas tecnológicas disponibles de acuerdo a los obje-

3. Analizando las diferentes alternativas tecnológicas en relación a su coste (es decir, de

4. Seleccionando la alternativa con la relación más favorable entre la inversión y el ren-

1.1.1 Costes directos

Los gastos administrativos son igualmente un concepto a tener en cuenta, dentro de lo

1.1.2 Costes indirectos

En ocasiones, también deberíamos de considerar los costes indirectos también denomi-

1.1.3 Otras mediciones de costes

La fiabilidad es la capacidad de un sistema informático para dar servicio a un usuario de

El rendimiento es la medida de la velocidad de respuesta de un sistema operativo o de

La escalabilidad será la capacidad de un sistema para adaptarse a una demanda crecien-

La marca, nombre, término, signo, símbolo o diseño, o la combinación de todos estos es la

1.1.5 Factores de bloqueo

1.2. Criterios derivados del entorno

• Posibilidad de observación: si serán visibles estos nuevos resultados o las mejoras

• Compatibilidad: será importante determinar si el nuevo sistema será compatible

• Complejidad: deberíamos tener en consideración si el sistema resultara sencillo

• Posibilidad de prueba: en muchos casos, para ayudar a la adopción de una nueva

La incertidumbre es una característica habitual en los sectores emergentes y en aquellos

Otro aspecto a tener en cuenta para la difusión de la tecnología, será la demanda de la

Cuando el coste de transición entre dos tecnologías es elevado, es complicado cam-

1.3. Criterios influenciables

1.5. Resumen del tema

2.1. Introducción a la virtualización de servidores

La virtualización, con la creación de los entornos de cliente servidor y el mundo de los

Figura 1. Modelo de expectativas de Gartner: evolución de la virtualización.

En la actualidad, todos los elementos de una infraestructura pueden funcionar de manera

• Virtualización de puestos de trabajo, con sus diferentes versiones, de aplicaciones,

• Virtualización del almacenamiento.

• Virtualización de las redes.

Figura 2. Árbol de trayectorias tecnológicas: trayectorias de la virtualización:

La virtualización, por lo tanto, ya se puede considerar una tecnología ampliamente exten-

2.2. Virtualizacion de servidores

2.2.1. Movimiento de máquinas

El entorno quedaría por lo tanto de la siguiente manera:

Figura 3. Infraestructura de virtualización.

Al estar ambos servidores o host conectados al mismo almacenamiento y tener, por lo

2.2.2. Alta disponibilidad

2.2.3. Gestión de recursos

2.2.4 Tolerancia a fallos

En este tipo de entornos, tradicionalmente se establecía un cluster, de tal manera que el

2.2.5 Recuperación de sede

La tolerancia frente a desastres en los entornos de virtualización se establece realizando

2.3. Grandes opciones

Propone un sistema de virtualización que permite todas las características descritas en

El máximo competidor de VMWare en el mundo de la virtualización es Microsoft. Micro-

Si en los primeros momentos de la virtualización, en los años 90 y principios de la década

La aproximación por parte de Microsoft es menos ambiciosa en cuanto a tecnología que

Las mayores características a tener en cuenta a la hora de seleccionar un sistema de vir-

Las soluciones pueden diferir en características técnicas avanzadas y en el rendimiento

• Oracle: Oracle, tras la adquisición de varias compañías de software, ha ido adqui-

El máximo competidor de VMWare en el mundo de la virtualización es Microsoft. Micro-

Si en los primeros momentos de la virtualización, en los años 90 y principios de la década

La aproximación por parte de Microsoft es menos ambiciosa en cuanto a tecnología que

Las mayores características a tener en cuenta a la hora de seleccionar un sistema de vir-

Las soluciones pueden diferir en características técnicas avanzadas y en el rendimiento

• Oracle: Oracle, tras la adquisición de varias compañías de software, ha ido adqui-

3. Virtualización y otras tecnologías

3.1. Virtualización del almacenamiento

A la hora de gestionar el almacenamiento, lo primero que nos viene a la cabeza es un