memoria del proyecto

POLÍTICAS DE SEGURIDAD DE ACCESOS A REDES LOCALES PARA LA PREVENCIÓN DE

FUGA DE DATOS

Autores:

Díaz, Peter

Villanueva, Alejandro

Fiz, Jesús

González, Nadia

Madrid, Mayo de 2011

POLÍTICAS DE SEGURIDAD DE ACCESOS A

REDES LOCALES PARA LA PREVENCIÓN DE FUGA DE DATOS

Proyecto de Fin de Máster presentado por:

Autores:

Díaz, Peter

Villanueva, Alejandro

Fiz, Jesús

González, Nadia

Directora: Santamaría, Pilar.

Madrid, Mayo de 2011

iii

Resumen

Las políticas de control de acceso de usuarios y refuerzo de dichas

políticas en el servidor de aplicaciones web, tienen como finalidad el control,

gestión, seguimiento y mantenimiento de toda la infraestructura del entorno

corporativo. Actualmente en la empresa Grupo Seidor, S.A. no existen políticas

de control de acceso para sus usuarios. La finalidad de estas políticas que se

desarrollaran para este trabajo de fin de master es de servir como punto de

referencia para el departamento de seguridad de la empresa, para el inicio de un

plan de acciones que lleven a un control de la plataforma, tecnológica

resguardando los datos de la empresa.

iv

Abstract

The access control policies for users and reinforcement of such policies on

the applications web server have as a purpose the control, management, tracking,

and maintenance of the entire corporate infrastructure environment. Actually on

the company Grupo Seidor, S.A. there are none access control policies for users.

The purpose of these policies that will be developed for this thesis is to serve as a

reference point for the IT security department of the company, for the beginning

of an action plan that lead to the control of the technological platform of the

company safeguarding its data.

v

Agradecimientos

A nuestra tutora Pilar Santamaría por su ofrecimiento inicial a llevar a cabo este

proyecto, así como a su dedicación y seguimiento en el transcurso del desarrollo

del mismo.

A mi padre Ramón Daniel Villanueva Fernández, y a mis hermanos Karin y

Moncho por ayudarme siempre que lo necesite. (Alejandro)

A mis padres María y Eloy, y especialmente a mi madre, que sufre una gran

enfermedad, por haberme ayudado a llegar a este punto de mi vida y a mi esposa

María, por ayudarme a compaginar mis estudios con el trabajo. (Jesús)

A mi Madre María Teresa Rosales y mi cuñado (Padre) Gustavo Pineda quienes

con su ejemplo de lucha y vida me dieron un gran ejemplo de superación y

sabiduría. A mis hermanos(as) Ricardo, Libia Jazmín quienes con sus cuidados y

crianza fueron guías en mi formación profesional. Especialmente a mi esposa por

su paciencia, apoyo y amor incondicional, te amo Mi Nena. (Peter)

A toda mi familia y amigos por su gran apoyo, pero en especial a mi madre

Manuela Gutiérrez Hondal, por estar siempre ahí, escucharme y apoyarme en todo

lo que hago y por inculcarme su espíritu de superación cada día, no sé qué haría

sin ella. Gracias por todo mamá, te quiero. (Nadia)

vi

Índice de Capítulos y Anexos

Página

Resumen……………………………………………………………...... iii

Abstract………………………………………………………………... iv

Agradecimientos………………………………………………….……. v

Índice de Capítulos y Anexos...……………..…………………………. vi

Índice de Tablas………………………………………………………... vii

Índice de Figuras………………………………………………………. xiv Capítulo I Introducción…………………….……………………...…... 15

Capítulo II Estado de la Cuestión.…………………………………….. 17

Capítulo III Descripción del Problema...………………………………. 18

Capítulo IV Solución Propuesta………………………………………. 20

Capítulo V Conclusiones………………………………………………. 103 Capítulo VI Trabajos Futuros…………………………………………. 104

Apéndices……………………………………………………………… 105

I Bibliografía……………………….………………...………………... 106

II Antecedentes………………………………………………………… 107

III Organigrama de la Empresa………………………………………… 112 IV Cisco 2010 Global Threat Report…………………………………… 113

V Forrester Consulting Paper about the Value of Corporate Secrets…… 120

vii

Índice de Tablas

Página

Tabla 1. Historial de Política: Sistema Operativo Cliente…………… 20

Tabla 2. Historial de Política: Sistema de antivirus………………….. 21

Tabla 3. Historial de Política: Sistema de control y admisión de estaciones

de trabajo………………………...……………………………………. 22

Tabla 4. Historial de Política: Red de cuarenta……..……………….. 23

Tabla 5. Historial de Política: Actualización Automática del Sistema

Operativo………………………………………………………….….. 24

Tabla 6. Historial de Política: Perfiles de admisión de los

usuarios……………………………………………………………….. 25

Tabla 7. Historial de Política: Red de invitados……………….…….. 26

Tabla 8. Historial de Política: Control de acceso a proveedores

externo………………………………………………………………… 27

Tabla 9. Historial de Política: Administración de las aplicaciones

de control y admisión…………………………………………………. 28

Tabla 10. Historial de Política: Dispositivos de electrónica de red

para la admisión de equipos electrónicos…………………………… 29

Tabla 11. Historial de Política: Servidores de control y admisión.... 30

viii

Tabla 12. Historial de Política: Control de admisión de usuarios…. 31

Tabla 13. Historial de Política: Actualización de los sistemas

operativos de los clientes…………………………………………… 32

Tabla 14. Historial de Política: Administración de los dispositivos

de electrónica de red……………………………………………….. 33

Tabla 15. Historial de Política: Admisión y control de Servidores

en la red corporativa………………………………………………. 34

Tabla 16. Historial de Política: Sistema de control de gestión y alertas. 35

Tabla 17. Historial de Política: Renovación de los equipos de

electrónica de red…………………………………………………… 36

Tabla 18. Historial de Política: Sistema de monitorización de la

electrónica de red…………………………………………………… 37

Tabla 19. Historial de Política: Solicitud de acceso a la red corporativa. 38

Tabla 20. Historial de Política: Actualización de las aplicaciones

tecnológicas………………………………………………………………. 39

Tabla 21. Historial de Política: Se debe especificar el control de acceso

de los usuarios al sistema………………………………………………… 40

Tabla 22. Historial de Política: Gestión y creación de contraseñas……. 41

Tabla 23. Historial de Política: Uso adecuado del sistema…………….. 42

ix

Tabla 24. Historial de Política: Respaldo de la información…………… 43

Tabla 25. Historial de Política: Uso de correo electrónico……………… 44

Tabla 26. Historial de Política: Roles de los usuarios en la Intranet…… 45

Tabla 27. Historial de Política: Contenidos de la página principal

de la Intranet……………………………………………………………… 46

Tabla 28. Historial de Política: Publicación de contenidos en la Intranet . 47

Tabla 29. Historial de Política: Responsable del avance de la Intranet…. 48

Tabla 30. Historial de Política: Clasificación de los contenidos

publicados en la Intranet…………………………………………………. 49

Tabla 31. Historial de Política: Control de descarga de aplicaciones…. 50

Tabla 32. Historial de Política: Notificación de incidentes en la Intranet .. 51

Tabla 33. Historial de Política: Formación del personal sobre seguridad

en la Intranet……………………………………………………………… 52

Tabla 34. Historial de Política: Responsables de seguridad de la

Intranet…………………………………………………………………… 53

Tabla 35. Historial de Política: Integridad en los contenidos de la

Intranet…………………………………………………………………… 54

Tabla 36. Historial de Política: Disponibilidad de la Intranet…………. 55

x

Tabla 37. Historial de Política: Acuerdos de confidencialidad………… 56

Tabla 38. Historial de Política: Autorización para procesar la

Información……………………………………………………………… 57

Tabla 39. Historial de Política: Auditabilidad de la Intranet………….. 58

Tabla 40. Historial de Política: Etiquetado de la información de la

Intranet…………………………………………………………………. 59

Tabla 41. Historial de Política: Identificación de los riesgos de la

Intranet…………………………………………………………………. 60

Tabla 42. Historial de Política: Funciones y responsabilidades de los

empleados respecto al uso de la Intranet………………………………. 61

Tabla 43. Historial de Política: Proceso disciplinario para los empleados

por el mal uso de la Intranet……………………………………………. 62

Tabla 44. Historial de Política: Retirada y modificación de los

derechos de acceso a la Intranet……………………………………….... 63

Tabla 45. Historial de Política: Controles de la red interna……………. 64

Tabla 46. Historial de Política: Control sobre el intercambio de

información………………………………………………………………… 65

Tabla 47. Historial de Política: Registro de auditorías de la Intranet…… 66

Tabla 48. Historial de Política: Registro de administración de la Intranet. 67

xi

Tabla 49. Historial de Política: Registro de usuarios de la Intranet…… 68

Tabla 50. Historial de Política: Equipo de usuario con acceso a la

Intranet desatendido…………………………………………………….. 69

Tabla 51. Historial de Política: Uso de servicios en red………………. 70

Tabla 52. Historial de Política: Identificación de los equipos en la

Intranet…………………………………………………………………. 71

Tabla 53. Historial de Política: Desconexión automática de sesión en

la Intranet………………………………………………………………. 72

Tabla 54. Historial de Política: Controles contra código malicioso….. 73

Tabla 55. Historial de Política: Controles contra códigos móviles…… 74

Tabla 56. Historial de Política: Controles de redes…………………… 75

Tabla 57. Historial de Política: Seguridad de los servicios de la red….. 76

Tabla 58. Historial de Política: Registro de auditoría…………………. 77

Tabla 59. Historial de Política: Uso del sistema de monitorización.…… 78

Tabla 60. Historial de Política: Protección del registro de información. 79

Tabla 61. Historial de Política: Registros del administrador y operador. 80

Tabla 62. Historial de Política: Registro de fallos………………………. 81

xii

Tabla 63. Historial de Política: Política de control de acceso………. 82

Tabla 64. Historial de Política: Registro de usuario…………………. 83

Tabla 65. Historial de Política: Gestión de privilegios………………. 84

Tabla 66. Historial de Política: Gestión de las claves secretas de los

Usuarios………………………………………………………………. 85

Tabla 67. Historial de Política: Revisión de los derechos de acceso

del usuario……………………………………………………………. 86

Tabla 68. Historial de Política: Uso de claves secretas……………… 87

Tabla 69. Historial de Política: Equipo desatendido…………………. 88

Tabla 70. Historial de Política: Uso de los servicios de red…………. 89

Tabla 71. Historial de Política: Computación y comunicaciones

Móviles……………………………………………………………….... 90

Tabla 72. Historial de Política: Control de vulnerabilidades………… 91

Tabla 73. Historial de Política: Reporte de eventos………………….. 92

Tabla 74. Historial de Política: Reporte de las debilidades en la

Seguridad……………………………………………………………… 93

Tabla 75. Historial de Política: Realización de revisiones y evaluaciones

Web………………………………………………………………………… 94

xiii

Tabla 76. Historial de Política: Log Management…………………………... 95

Tabla 77. Historial de Política: Copia en red de los Log…………………… 96

Tabla 78. Historial de Política: Revisión de políticas de seguridad y

cumplimiento técnico………………………………………………………… 97

Tabla 79. Historial de Política: Auditorías de sistemas……………………… 98

Tabla 80. Historial de Política: Monitorización de administración de sistemas. 99

Tabla 81. Historial de Política: Monitorización de uso del sistema………… 100

Tabla 82. Historial de Política: Protección y respaldo de los Log…………. 101

xiv

Índice de Figuras

Página

Organigrama de la Empresa………………………………………….... 112

15

CAPITULO I

INTRODUCCIÓN

El Grupo Seidor es una empresa española cuyo origen data del año 1982 en

Cataluña, con un capital 100 % español y que ha estado siempre entre las 50

mejores empresas TIC españolas. Desde el año 2005 ha experimentado una

expansión a pasos acelerados en toda España y Latinoamérica, fundamentalmente

por la comercialización de los sistemas SAP, donde es el líder en España llegando

a lograr importantes premios a nivel nacional e internacional.

El grupo Seidor en la actualidad disponen de sistemas que administran,

controlan y monitorean los principales servicios y aplicaciones de su red local

corporativa, todo esto ha llevado al desarrollo de su infraestructura y un

crecimiento acelerado de sus procesos tecnológicos. Con la finalidad de

controlar y gestionar cada uno de los sistemas que componen la estructura

tecnología del Grupo Seidor en especial la seguridad en tecnología de la

información y comunicaciones conocida por sus siglas TIC, se han desarrollado

en este trabajo de fin de master una serie de políticas que contribuyen al

control, supervisión, mantenimiento, auditoria y gestión de los sistemas en el

Grupo Seidor.

Teniendo en cuenta lo antes expuesto dichas políticas llevan un control y

gestión de los accesos a las aplicaciones, validaciones, servicios, servidores,

estaciones de trabajo y en general toda la plataforma que soporta la

infraestructura.

El Grupo Seidor, tomando en cuenta la seguridad en las TIC, entiende que

no es necesario tener como único punto un responsable o un gran departamento de

seguridad, sino políticas que regulen a estas personas en sí mismas o a estos

departamentos involucrados.

16

Uno de los principales temores dentro del Grupo Seidor es que en la

actualidad por no contar con políticas de seguridad en sus redes locales, han

experimentado fugas de datos que han arrojado reflejan pérdidas económicas

millonarias. Un ejemplo muy parecido de estas fugas de información se han

visto últimamente como el de la empresa Sony donde su producto estrella

PlayStation por un fallo en su seguridad interna (posiblemente por no contar con

políticas definidas), que se ha traducido en una fuga de datos de los suscriptores

de esta red de usuarios, en la mayoría personas que jugaban y tenían datos

personales en los servidores de la compañía.

Como reflexión decimos que las políticas de seguridad en muchos casos

son subestimadas por las empresas, no obstante tienen el poder de crear

conciencia en las personas, como en todo sistema eco ambiental donde interactúa

el hombre y los sistemas las políticas son como las leyes en los países, marcan la

pauta del comportamiento y actuación de las personas en determinadas

situaciones. Pero al igual que las leyes en algunos casos son mal interpretadas

o simplemente no se cumplen. Debemos tener siempre presente que las

políticas de seguridad son necesarias si queremos tener una organización con

parámetros que permitan regular el funcionamiento adecuado de los

ambientes y plataformas informáticas garantizando un verdadero control del

recurso humano y de los sistemas.

17

CAPITULO II

ESTADO DE LA CUESTIÓN

Al momento del desarrollo de este trabajo no existían dentro de la

organización Grupo Seidor Políticas de Control y Acceso a la red local, esto tenía

como consecuencia la fuga de información de todos los desarrollos

correspondientes a nuevos proyectos que se desarrollaban en el departamento de

Desarrollo de Negocios. La finalidad de este trabajo es poder brindar los medios

al departamento de seguridad de poder mitigar la fuga de información y tener un

control de los usuarios que acceden a los recursos de la red local, pudiendo así

tener la supervisión, la trazabilidad y la auditoria de toda la información de

carácter sensible y confidencial que circula dentro de la red.

La protección de los datos es de alta importancia para el departamento de

desarrollo de negocios y por ello ha pedido al departamento de seguridad de la

organización la creación de políticas de seguridad que permitan el control y

mitigación de los posibles fallos no humanos y humanos que puedan estar

desarrollándose en Grupo Seidor. Es un punto a destacar que la organización está

experimentando un crecimiento exponencial de clientes lo que ha llevado el

último año de operaciones a crecer el personal de consultores y administrativos,

en muchos casos han venido personal de la competencia y en pro de proteger la

fuga de la información han pedido la implementación de políticas de seguridad.

Casos que se han desarrollado en otras corporaciones como Sony Corporation con

el caso de su producto estrella Play Station Network1, donde un fallo de seguridad

permitió la fuga de millones de datos de sus suscriptores ha encendido la alerta no

solo a la gerencia de seguridad de Grupo Seidor sino a todos los departamentos de

Seguridad de todas las empresas a nivel mundial.

1 2011. “Comunicado de Prensa de Sony Online Entertainment sobre cuestiones de seguridad”.

“blog.es.playstation.com”. (Consultada: 05/05/2011)

18

CAPITULO III

DESCRIPCIÓN DEL PROBLEMA

La empresa Grupo Seidor S.A. en la actualidad no cuenta con políticas de

seguridad para el control de los usuarios y a sus servidores de aplicaciones web,

en los últimos años se ha incrementado el robo de información digital por parte de

los usuarios internos por no tener control sobre sus servidores web, al no existir

políticas de seguridad que regulen los accesos y lleven un control de los usuarios

que accedan de manera regulada a la información alojada en sus servidores de

aplicaciones web.

La sustracción y robo de información clasificada le ha llevado a la pérdida

de negocios y clientes en valores monetarios superiores a 800.000 euros por año,

lo que representa una cuarta parte del ingreso anual en ventas solo en servicios de

consultoría.

Estas políticas de seguridad serán reguladas, administradas y puesta en

marcha por el departamento de seguridad y redes de la empresa, teniendo como

primera misión el poder regular los accesos a los usuarios internos y a los

servidores de aplicaciones web.

Los servidores de aplicaciones web, contienen los sistemas financieros,

contables y administrativos soportados todos ellos en los sistemas ERP de SAP2

Business One. Estos módulos gestionan el 80 % de las operaciones de la

organización.

2

2011. “SAP España, Pequeñas y Medianas Empresas”. http://www.sap.com/spain

/sme/solutions/businessmanagement/businessone/index.epx. (Consultada: 16/03/2011)

19

El requerimiento para la elaboración y estructuración de unas políticas de

seguridad que aplique el entorno organizacional interno con el fin de resguardar la

información crítica para la empresa como son sus clientes y proveedores externos.

Estas políticas a ser implementadas llevaran un control para la prevención no solo

de este tipo de ataques que se vinculan al factor humano sino también a los

informáticos que día a día se desarrollan incrementalmente trayendo en ocasiones

perdidas millonarias y paradas inesperadas a las organizaciones.

20

CAPITULO IV

SOLUCIÓN PROPUESTA

Políticas de admisión y control de usuarios:

Tabla 1. Historial de Política: Sistema Operativo Cliente.

Política: Sistema Operativo Cliente.

Comentario: Con esta política se pretende especificar el tipo de sistema operativo

que se autoriza para acceder a la red corporativa. El sistema operativo cliente será

el indicado por el responsable del departamento de seguridad y no se podrá operar

con ningún otro sistema operativo que no esté autorizado por el responsable del

departamento de seguridad.

Políticas relacionadas: “Sistema operativo cliente”.

Política dirigida a: Todos.

Ambientes de seguridad: Todos.

Fecha: 13 de febrero de 2011

Fecha de revisión:

13 de febrero de 2012

Versión: 1.0

Revisión: Departamento de seguridad

Revisor: Director de Seguridad

Autor: Peter Díaz

21

Tabla 2. Historial de Política: Sistema de antivirus.

Política: Sistema de antivirus.

Comentario: Esta política establece los equipos corporativos deberán de tener un

sistema operativo el cual será actualizado periódicamente por los servidores que

prestan el servicio de actualización de huellas, este antivirus será administrado y

controlado por el departamento de seguridad.

Políticas relacionadas: “Sistema Antivirus”.




Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

22

Tabla 3. Historial de Política: Sistema de control y admisión de estaciones de

trabajo.

Política: Sistema de control y admisión de estaciones de trabajo.

Comentario: Esta política específica que las estaciones de trabajo que se

conectan a la red corporativa solo recibirán los servicios si pertenece a un grupo

específico del entorno tecnológico y cumpla con las reglas definidas por el

departamento de seguridad de la corporación.

Políticas relacionadas: “Admisión y control”.




Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

23

Tabla 4. Historial de Política: Red de cuarenta.

Política: Red de cuarenta.

Comentario: Esta política especifica qué las estaciones de trabajo que no

cumplan con las reglas definidas por el departamento de seguridad de la

corporación, pasar a una red de cuarentena con servicios limitados que serán

definidos previamente por el departamento de seguridad de la corporación.

Políticas relacionadas: “Control y Admisión”.




Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

24

Tabla 5. Historial de Política: Actualización Automática del Sistema Operativo.

Política: Actualización Automática del Sistema Operativo.

Comentario: Esta política establece que las estaciones de trabajo y servidores

contaran con un sistema automatizado para la actualización y parcheo de sus

sistemas operativos, dicho sistema será administrado y controlado por el

departamento de seguridad de la corporación y contara con la supervisión del

responsable del departamento





Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

25

Tabla 6. Historial de Política: Perfiles de admisión de los usuarios.

Política: Perfiles de admisión de los usuarios.

Comentario: Esta política establece los perfiles de los usuarios en la red

corporativa, el usuario tendrá acceso a los sistemas de la corporación de acuerdo

al rol y las funciones que desempeñe en la organización, de esta manera se

establecerán niveles de acceso para cada aplicación, base de datos, sistema web o

cualquiera que aplique en el entorno corporativo. Estos niveles serán establecidos

por el departamento de seguridad de la organización.

Políticas relacionadas: “Perfiles de los usuarios”.




Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

26

Tabla 7. Historial de Política: Red de Invitados.

Política: Red de invitados.

Comentario: Se contara con una red de invitados la cual tendrá una conectividad

totalmente aislada a la red corporativa y cuyo acceso será solo autorizado por el

departamento de seguridad de la corporación.

Políticas relacionadas: “Control y Admisión”.




Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

27

Tabla 8. Historial de Política: Control de acceso a proveedores externos.

Política: Control de acceso a proveedores externos.

Comentario: Para evitar que los equipos portátiles y electrónicos de proveedores

externos que se conectan a la red corporativa, dicha autorización y chequeo previo

será exclusivamente autorizado por el departamento de seguridad de la

corporación, con el fin de evitar que dichos equipos puedan contener software

malicioso o no cumplan con las políticas establecidas anteriormente.

Políticas relacionadas: “Control y admisión”.




Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

28

Tabla 9. Historial de Política: Administración de las aplicaciones de control y

admisión.

Política: Administración de las aplicaciones de control y admisión.

Comentario: Es necesario tener un responsable que se encargue de administrar

los dispositivos, servidores y aplicaciones que control, autoricen y administren el

acceso a la red corporativa y sus recursos asociados. Este responsable será el

encargado de dar un reporte y alertar de las posibles vulnerabilidades e

irregularidades que pueda sufrir la organización. Este administrador dependerá

directamente del responsable del departamento de seguridad.

Políticas relacionadas: “Responsables del sistema de control y admisión”.




Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

29

Tabla 10. Historial de Política: Dispositivos de electrónica de red para la

admisión de equipos electrónicos.

Política: Dispositivos de electrónica de red para la admisión de equipos

electrónicos.

Comentario: Solo se permitirán la implementación de equipos de electrónica de

red que cumplan con el protocolo 802.1X para garantizar que dichos equipos

tendrán la capacidad de operar bajo normas establecidas por el departamento de

seguridad, garantizando el control y administración de los equipos que se

conecten a la red corporativa.





Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

30

Tabla 11. Historial de Política: Servidores de control y admisión.

Política: Servidores de control y admisión.

Comentario: Se deberá contar con servidores que presten los servicios de

admisión y control en la red corporativa. Estos servidores deberán cumplir con

las normas establecidas anteriormente y serán capaces de ser administrados de

manera autónoma con la mínima intervención del personal del departamento de

seguridad





Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

31

Tabla 12. Historial de Política: Control de admisión de usuarios.

Política: Control de admisión de usuarios.

Comentario: Los usuarios que se conecten a la red corporativa deberán cumplir

con las normas establecidas por el departamento de seguridad de la organización,

y bajo ningún concepto podrán saltarse los procedimientos de admisión y control

a la red corporativa

Políticas relacionadas: “Control de usuarios”.




Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

32

Tabla 13. Historial de Política: Actualización de los sistemas operativos de los

clientes.

Política: Actualización de los sistema operativos de los clientes.

Comentario: La actualización de los sistemas operativos de las estaciones de

trabajo estará a cargo del departamento de tecnología de la organización, bajo la

supervisión del departamento de seguridad. Ambos departamento se coordinaran

para tomar en cuenta cuáles serán los sistemas operativos implicados en el

momento de su actualización.

Políticas relacionadas: “Sistemas operativos”.




Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

33

Tabla 14. Historial de Política: Administración de los dispositivos de

electrónica de red.

Política: Administración de las dispositivos de electrónica de red.

Comentario: Se contara con un responsable de administrar y controlar los

dispositivos de electrónica de red que interconectan la red corporativa, dicho

responsable dependerá del departamento de seguridad de la organización.

Políticas relacionadas: “Personal Administrativo”.




Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

34

Tabla 15. Historial de Política: Admisión y control de Servidores en la red

corporativa.

Política: Admisión y control de Servidores en la red corporativa.

Comentario: Solo se permitirán la instalación de servidores que cumplan con las

normas establecidas por el departamento de seguridad y sean compatibles con el

protocolo 802.1X, todos los servidores que se conecten a la electrónica de red

deben de tener la capacidad de auto gestionarse con la mínima intervención de los

administradores.





Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

35

Tabla 16. Historial de Política: Sistema de control de gestión y alertas.

Política: Sistema de control de gestión y alertas.

Comentario: Se contara con un sistema de gestión y alertas que permita notificar

a los responsables del departamento de seguridad y tecnología en caso de alguna

contingencia o alarma preventiva. Estas alertas serán pre configuradas en el

sistema de acuerdo a las aplicaciones que se alojen en cada servidor y tomando en

cuenta su criticidad para la organización.

Políticas relacionadas: “Sistema de gestión y alertas”.




Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

36

Tabla 17. Historial de Política: Renovación de los equipos de electrónica de red.

Política: Renovación de los equipos de electrónica de red.

Comentario: Se renovaran y se sacaran de su vida útil todos los equipos de

electrónica de red que no cumplan con el protocolo 802.1X, esto con el fin de

tener un equipamiento estándar que cumpla con los mínimos requerimientos para

la gestión de la plataforma tecnológica de la corporación.





Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

37

Tabla 18. Historial de Política: Sistema de monitorización de la electrónica de

red.

Política: Sistema de monitorización de la electrónica de red.

Comentario: Se debe contar con un sistema de monitorización que permita ver en

tiempo real el funcionamiento y desempeño de los equipos de electrónica de red.

Dicho sistema tiene que cumplir con las normas establecidas por el departamento

de seguridad de la corporación, bajo la aprobación del responsable de seguridad.

Políticas relacionadas: “Sistema de monitorización”.




Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

38

Tabla 19. Historial de Política: Solicitud de acceso a la red corporativa.

Política: Solicitud de acceso a la red corporativa.

Comentario: Todo equipo electrónico, dispositivo, portátil y/o servidor que

cumpla una función critica dentro de la organización deberá ser autorizado

previamente por el departamento de seguridad de la corporación antes de ser

conectado a la plataforma tecnológica.





Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

39

Tabla 20. Historial de Política: Actualización de las aplicaciones

tecnológicas.

Política: Actualización de las aplicaciones tecnológicas.

Comentario: Solo se permitirán la implementación de aplicaciones tecnológicas

compatibles con los sistemas de admisión y control descritos anteriormente, bajo

ningún concepto se implementaran aplicaciones que no sean compatibles con la

plataforma tecnológica de la corporación





Fecha de revisión:


Versión: 1.0



Autor: Peter Díaz

40

Políticas de protección de la Intranet y sus

contenidos:

Tabla 21. Historial de Política: Se debe especificar el control de acceso de

los usuarios al sistema.

Política: Se debe especificar el control de acceso de los usuarios al sistema.

Comentario: Con esta política se pretende especificar como deben acceder los

usuarios al sistema, desde dónde y de qué forma deben autentificarse. El control

de acceso está ligado la autentificación, ya que para poder acceder al sistema es

necesario autentificarse. Mediante el control de acceso el usuario deberá

introducir su nombre de usuario y contraseña y de esta forma tendrá acceso a los

recursos de la intranet. Todos los usuarios deberán acceder al sistema utilizando

algún programa que permita una comunicación segura y cifrada.

Políticas relacionadas: “Autentificación de personal”.




Fecha de

revisión:


Versión: 1.0


Revisor: Auditor de seguridad

Autor: Nadia González

41

Tabla 22. Historial de Política: Gestión y creación de contraseñas.

Política: Gestión y creación de contraseñas.

Comentario: Esta política establece qué persona asignará la contraseña, la

longitud que debe tener, su formato, la forma en que debe ser comunicada, etc.

Las contraseñas son el método de autentificación más común y con todas estas

medidas se pretende que los usuarios se autentifiquen de manera segura y así

garantizar la protección contra ataques en la intranet.

Políticas relacionadas: “Asignación de contraseñas”.




Fecha de

revisión:


Versión: 1.0


Revisor: Auditor de Seguridad


42

Tabla 23. Historial de Política: Uso adecuado del sistema.

Política: Uso adecuado del sistema.

Comentario: Esta política específica lo que se considera un uso adecuado o

inadecuado del sistema por parte de los usuarios, así como lo que está permitido y

lo que está prohibido dentro del sistema de información. Está prohibido entre

otras cosas el ejecutar programas que intenten adivinar contraseñas alojadas en las

máquinas locales o remotas.

Políticas relacionadas: “Normas del sistema de información”.




Fecha de

revisión:


Versión: 1.0




43

Tabla 24. Historial de Política: Respaldo de la información.

Política: Respaldo de la información.

Comentario: Esta política especifica qué información debe respaldarse, qué

medios de respaldo utilizar, cada cuanto tiempo debe respaldarse, cómo deberá ser

respaldada la información, dónde deberán almacenarse los respaldos etc. Un

ejemplo sería que el administrador del sistema es el responsable de realizar los

respaldos de la información. Cada mes deberá efectuarse un respaldo completo del

sistema y cada día deberán ser respaldados todos los archivos que fueron

modificados o creados. La información respaldada deberá ser almacenada en un

lugar seguro y distante del sitio de trabajo.

Políticas relacionadas: “Métodos de respaldo de la información”.




Fecha de revisión:


Versión: 1.0




44

Tabla 25. Historial de Política: Uso de correo electrónico.

Política: Uso de correo electrónico.

Comentario: Esta política establece tanto el uso adecuado como inadecuado del

servicio de correo electrónico, los derechos y obligaciones que el usuario debe

conocer y cumplir al respecto. Un ejemplo es que el usuario es la única persona

autorizada para leer su propio correo, a menos que él autorice explícitamente a

otra persona para hacerlo, o bien que su cuenta esté involucrada en algún

incidente de seguridad de la empresa.

Políticas relacionadas: “Obligaciones de los usuarios con el correo electrónico”.




Fecha de revisión:


Versión: 1.0




45

Tabla 26. Historial de Política: Roles de los usuarios en la Intranet.

Política: Roles de los usuarios en la intranet.

Comentario: Esta política establece los permisos de los usuarios en el acceso y

en los contenidos de la intranet. Es decir, dependiendo del rol que se le haya

asignado, el usuario tendrá acceso a una determinada información, ya que no

todos los usuarios pueden tener el mismo nivel jerárquico dentro de la empresa.

Políticas relacionadas: “Permisos de los usuarios”.




Fecha de revisión:


Versión: 1.0




46

Tabla 27. Historial de Política: Contenidos de la página principal de la Intranet.

Política: Contenidos de la página principal de la Intranet.

Comentario: La página principal de la Intranet es el espacio más demandado del

sitio en cada área de la empresa, ya que todos tienen enlace directo a su

información. Cada equipo de la Intranet debe tener establecido lo que tiene que

estar publicado y lo que no en la página principal.

Políticas relacionadas: “Acceso a la información”.




Fecha de revisión:


Versión: 1.0




47

Tabla 28. Historial de Política: Publicación de contenidos en la Intranet.

Política: Publicación de contenidos en la Intranet.

Comentario: Para evitar que la Intranet se convierta en “un vertedero de

documentos de segunda mano” es importante que la información que ya haya sido

comunicada al personal a través de cualquier mecanismo como el correo

electrónico no vuelva a ser publicada en la Intranet.

Políticas relacionadas: “Acceso a la información”.




Fecha de revisión:


Versión: 1.0




48

Tabla 29. Historial de Política: Responsable del avance de la Intranet.

Política: Responsable del avance de la Intranet.

Comentario: Es necesario tener un responsable para impulsar el avance de la

Intranet, el desarrollo de sus estrategias y la gestión de los elementos clave del

sitio. Esto es necesario para que la Intranet sea consistente, coherente y eficaz. El

responsable del avance de la Intranet tiene que intentar mejorarla en todo

momento, utilizar una serie de estrategias para su mejora y gestionar elementos

como la página principal, la búsqueda etc.

Políticas relacionadas: “Responsables de la información”.




Fecha de revisión:


Versión: 1.0




49

Tabla 30. Historial de Política: Clasificación de los contenidos publicados en la

Intranet.

Política: Clasificación de los contenidos publicados en la Intranet.

Comentario: No todos los contenidos de la Intranet deben ser publicados, ya que

la información se clasifica en distintos niveles de seguridad, puede ser pública,

privada o confidencial, y esto ha de tenerse en cuenta a la hora de la publicación

de contenidos. Habrá cierta información pública, es decir, accesible a todos los

usuarios de la Intranet, la privada, a la que sólo tendrán acceso ciertos usuarios,

dependiendo de su rol, y la confidencial que no es conveniente que sea publicada

en la Intranet, pero en caso de serlo solo debe tener acceso la persona con los

permisos necesarios.

Políticas relacionadas: “Clasificación de la información”.




Fecha de revisión:


Versión: 1.0




50

Tabla 31. Historial de Política: Control de descarga de aplicaciones.

Política: Control de descarga de aplicaciones.

Comentario: Es necesario tener un control de las aplicaciones que se descarguen

los empleados de Internet, ya que las aplicaciones pueden contener malware que

infecte los ordenadores, de forma que cuando el empleado acceda a la Intranet ese

malware sea transmitido y por tanto perjudique al resto de equipos de la empresa.

Políticas relacionadas: “Control de aplicaciones”.




Fecha de revisión:


Versión: 1.0




51

Tabla 32. Historial de Política: Notificación de incidentes en la Intranet.

Política: Notificación de incidentes en la Intranet.

Comentario: Todos los usuarios de la Intranet deben informar al departamento de

Seguridad de la empresa de cualquier incidencia dentro de la Intranet, tanto

errores como el mal uso de la misma, además de los fallos en la disponibilidad del

sitio.

Políticas relacionadas: “Notificación de incidencias”.




Fecha de revisión:


Versión: 1.0




52

Tabla 33. Historial de Política: Formación del personal sobre seguridad en la

Intranet.

Política: Formación del personal sobre seguridad en la Intranet.

Comentario: Dentro de la empresa deben impartirse cursos sobre seguridad a

todos los empleados, para concienciar de los peligros que hay por la red y de esta

forma evitar vulnerabilidades producidas por errores humanos. Con todo esto se

pretende evitar el mal uso de la Intranet por parte de los usuarios así como los

problemas que eso supone.

Políticas relacionadas: “Formación del personal”.




Fecha de revisión:


Versión: 1.0




53

Tabla 34. Historial de Política: Responsables de seguridad de la Intranet.

Política: Responsables de seguridad de la Intranet.

Comentario: En la empresa deben existir unas figuras claras de autoridad

respecto de la seguridad de la Intranet, esto quiere decir que estas personas serán

las encargadas de establecer una serie de normas de uso seguro para los usuarios,

además de ser los responsables si existe algún problema de seguridad en la

Intranet.

Políticas relacionadas: “Responsables de la información”.




Fecha de revisión:


Versión: 1.0




54

Tabla 35. Historial de Política: Integridad en los contenidos de la

Intranet.

Política: Integridad en los contenidos de la Intranet.

Comentario: Todos los contenidos publicados en la Intranet deben ser íntegros,

es decir, que no puedan ser modificados por una persona que no tenga los

permisos necesarios para ello. Con esto se pretende que la información publicada

sea veraz.

Políticas relacionadas: “Integridad de la información”.




Fecha de revisión:


Versión: 1.0




55

Tabla 36. Historial de Política: Disponibilidad de la Intranet.

Política: Disponibilidad de la Intranet.

Comentario: La Intranet debe estar en todo momento disponible para que los

usuarios puedan acceder a ella, ya que es totalmente necesaria para realizar el

trabajo de la empresa. En caso de no estar disponible, deberá ser reparada en el

menor tiempo posible para no obstaculizar las labores diarias de la empresa.

Políticas relacionadas: “Disponibilidad de los servicios web”.




Fecha de revisión:


Versión: 1.0




56

Tabla 37. Historial de Política: Acuerdos de confidencialidad.

Política: Acuerdos de confidencialidad.

Comentario: Es necesario identificar y revisar los requerimientos de

confidencialidad de la Intranet, así como los acuerdos de no divulgación de

contenidos, para proteger la información contenida en la Intranet y garantizar la

confidencialidad de la información de la empresa.

Políticas relacionadas: “Confidencialidad de la información”.




Fecha de

revisión:


Versión: 1.0




57

Tabla 38. Historial de Política: Autorización para procesar la

información.

Política: Autorización para procesar la información.

Comentario: Cada vez que sea necesario procesar la información de la Intranet,

tal como añadir, modificar o eliminar información, será necesario solicitar a los

responsables de seguridad una autorización para llevar a cabo dicho proceso. Con

esto se pretende tener un control sobre la información y así evitar su pérdida y

mantener su integridad y confidencialidad.

Solicitar una autorización a los responsables de seguridad de la empresa

evita al personal la toma de decisiones sobre seguridad que pueden provocar algún

daño en el sistema de información al no tener experiencia en ese campo.

Políticas relacionadas: “Autorización de recursos”.




Fecha de revisión:


Versión: 1.0




58

Tabla 39. Historial de Política: Auditabilidad de la Intranet.

Política: Auditabilidad de la Intranet.

Comentario: La Intranet debe ser totalmente auditable, ya que para proteger

todos sus contenidos es necesario realizar auditorías de seguridad cada cierto

tiempo y así descubrir las vulnerabilidades del sitio. Auditar la Intranet es un

punto crucial de la seguridad de la información, ya que los contenidos de ésta son

únicamente de la empresa y por ello no pueden ser vistos ni modificados por

personas ajenas a ella.

De la auditabilidad depende que el sistema mejore y sea más seguro.

Políticas relacionadas: “Auditabilidad del sistema de información”.




Fecha de revisión:


Versión: 1.0




59

Tabla 40. Historial de Política: Etiquetado de la información de la

Intranet.

Política: Etiquetado de la información de la Intranet.

Comentario: Desarrollo e implementación de una serie de procedimientos para

etiquetar y manejar la información siguiendo el esquema adoptado por la empresa.

El etiquetado de información es importante para su clasificación y para su

intercambio.

La información será etiquetada mediante una serie de mecanismos

electrónicos y será clasificada como sensible, crítica, privada, pública... según su

relevancia para la empresa.

Políticas relacionadas: “Etiquetado y manejo de la información”.




Fecha de revisión:


Versión: 1.0




60

Tabla 41. Historial de Política: Identificación de los riesgos de la Intranet.

Política: Identificación de los riesgos de la Intranet.

Comentario: Para poder tener una Intranet segura, hay que identificar todos los

riesgos a los que se encuentra expuesta y así poder desarrollar las medidas de

protección contra tales riesgos.

Uno de los principales riesgos es el acceso de terceros, por lo que una de

las medidas será proteger la información contra terceras personas ajenas a la

empresa que no tengan permiso para acceder a ella.

La identificación de riesgos proporcionará a la empresa un mayor control

sobre la Intranet y sobre la información que ésta contiene.

Políticas relacionadas: “Riesgos del sistema de información”.




Fecha de revisión:


Versión: 1.0




61

Tabla 42. Historial de Política: Funciones y responsabilidades de los empleados

respecto al uso de la Intranet.

Política: Funciones y responsabilidades de los empleados respecto al uso de la

Intranet.

Comentario: El personal tendrá definidas una serie de normas de uso de la

Intranet que deberán ser cumplidas en todo momento. Además cada empleado

tendrá una serie de responsabilidades que cumplir y asumir, ya que si se produce

algún incidente bien sea por accidente o intencionadamente los responsables de

seguridad deben saber en todo momento la causa por la que se ha producido y la

persona que lo ha causado. Cada empleado tendrá una función definida y tendrá

que cumplirla sin sobrepasar los límites permitidos. Por todo esto es muy

importante concienciar a los empleados de que deben cumplir las normas e

informar de cualquier incidencia lo antes posible.

Políticas relacionadas: “Normas de uso de la Intranet”.




Fecha de revisión:


Versión: 1.0




62

Tabla 43. Historial de Política: Proceso disciplinario para los empleados por el

mal uso de la Intranet.

Política: Proceso disciplinario para los empleados por el mal uso de la Intranet.

Comentario: Debe existir un proceso disciplinario en la empresa para todos los

empleados que hayan provocado alguna violación de la seguridad de la Intranet.

Como se ha definido en otras políticas sobre las normas de los empleados,

se abrirá un proceso disciplinario a todo empleado que incumpla las normas y que

por tanto perjudique a la seguridad de la Intranet.

Cada proceso disciplinario dependerá de la gravedad de la violación de

seguridad cometida y de la intencionalidad de la misma, ya que no se tratará igual

un caso de un empleado que lo realizase conscientemente como un caso de un

empleado que lo hiciese de forma accidental.

Políticas relacionadas: “Normas de uso de la Intranet”.




Fecha de revisión:


Versión: 1.0




63

Tabla 44. Historial de Política: Retirada y modificación de los derechos de

acceso a la Intranet.

Política: Retirada y modificación de los derechos de acceso a la Intranet.

Comentario: Cada vez que un empleado abandone su puesto de trabajo o bien se

le asigne otro diferente, sus derechos de acceso serán modificados de igual forma.

Esto quiere decir que habrá una serie de pautas definidas para eliminar los

derechos de acceso de antiguos empleados a la Intranet y para la modificación de

estos derechos en caso de cambiar de puesto de trabajo dentro de la misma

empresa. Con esto se pretende tener un control sobre el acceso a la Intranet, ya

que el personal varía continuamente y no se puede permitir que una persona que

no siga en la empresa siga teniendo un control de acceso a la Intranet de la

misma, al igual que una persona que varíe de puesto de trabajo dentro de la

empresa no puede tener el mismo control de acceso que tenía anteriormente, ya

que su perfil ha cambiado.

Políticas relacionadas: “Control de acceso”.




Fecha de revisión:


Versión: 1.0




64

Tabla 45. Historial de Política: Controles de la red interna.

Política: Controles de la red interna.

Comentario: Toda la red interna debe estar correctamente controlada y

gestionada, para poder mantener la seguridad de los sistemas y de las aplicaciones

frente a las amenazas.

Toda la información que circula por la red interna de la empresa debe estar

controlada en todo momento, ya que se puede producir un ataque en cualquier

momento y esa información necesita estar segura y protegida.

Políticas relacionadas: “Controles de red del sistema de información”.




Fecha de revisión:


Versión: 1.0




65

Tabla 46. Historial de Política: Control sobre el intercambio de

información.

Política: Control sobre el intercambio de información.

Comentario: Todo el intercambio de información que se maneja a través de la

Intranet deberá ser controlado mediante una serie de recursos de comunicación

para evitar que la información circule sin control ninguno por la empresa y en

algunos casos fuera de ella.

Con esta serie de recursos y mecanismos se pretende que la información

esté siempre protegida, de forma que no todo el personal tenga acceso a ella y

mucho menos personas ajenas a la empresa.

Políticas relacionadas: “Control de la información del sistema”.




Fecha de revisión:


Versión: 1.0




66

Tabla 47. Historial de Política: Registro de auditorías de la Intranet.

Política: Registro de auditorías de la Intranet.

Comentario: Cada vez que se realice una auditoría de la Intranet, se deben

realizar registros de las actividades de los empleados que usan la Intranet, y las

excepciones y eventos de seguridad de la misma.

Estos registros se deben mantener durante un período de tiempo acordado

por los responsables de seguridad de la empresa para servir como prueba en

futuras auditorías o investigaciones sobre incidencias de seguridad, y además para

supervisar el control de acceso.

Políticas relacionadas: “Auditabilidad del sistema de información”.




Fecha de revisión:


Versión: 1.0




67

Tabla 48. Historial de Política: Registro de administración de la Intranet.

Política: Registro de administración de la Intranet.

Comentario: Cada vez que el administrador de la Intranet acceda al sistema, se

debe guardar un registro de accesos y de operaciones que ha realizado.

Con todo esto se pretende llevar un control sobre las acciones realizadas

dentro de la Intranet y comprobar si es realmente el administrador el que accede al

sistema o si es alguien que ha conseguido las claves y está suplantando su

identidad.

Políticas relacionadas: “Registro de accesos al sistema”.




Fecha de revisión:


Versión: 1.0




68

Tabla 49. Historial de Política: Registro de usuarios de la Intranet.

Política: Registro de usuarios de la Intranet.

Comentario: Debe establecerse un procedimiento de registro y eliminación de

usuarios para conceder y revocar el acceso al sistema y por tanto a sus servicios.

De esta forma se pretende llevar un control sobre el acceso de los usuarios

a la Intranet, de forma que cada vez que se asignen permisos de acceso y se

revoquen haya un registro que lo muestre, y así cada cierto tiempo se comprobará

dicho registro controlando que todas las operaciones se han realizado

correctamente.

Políticas relacionadas: “Registro de accesos al sistema”.




Fecha de revisión:


Versión: 1.0




69

Tabla 50. Historial de Política: Equipo de usuario con acceso a la Intranet

desatendido.

Política: Equipo de usuario con acceso a la Intranet desatendido.

Comentario: Cuando el usuario acceda a los servicios de la Intranet, deberá

cerrar la sesión o bloquear el equipo cada vez que necesite ausentarse de su

puesto.

En caso contrario cualquier persona podría utilizar el acceso para obtener

información privada que se encuentre en la Intranet y manipularla, además de

información personal del usuario en el equipo.

De esta forma se consigue proteger el acceso no autorizado a la Intranet y

a los equipos de otros usuarios que pueden contener información importante para

la empresa.

Políticas relacionadas: “Responsabilidades de los usuarios”.




Fecha de revisión:


Versión: 1.0




70

Tabla 51. Historial de Política: Uso de servicios en red.

Política: Uso de los servicios en red.

Comentario: Se debe proporcionar a los usuarios únicamente el acceso a los

servicios para los que hayan sido autorizados, es decir, dependiendo de los

permisos que tengan asignados podrán usar una serie de servicios u otros.

De esta forma se controlará el uso de recursos por parte de los usuarios, de

forma que los responsables de seguridad tengan un control sobre la información

que se proporciona a los usuarios.

Políticas relacionadas: “Control de acceso a la red”.




Fecha de revisión:


Versión: 1.0




71

Tabla 52. Historial de Política: Identificación de los equipos en la Intranet.

Política: Identificación de los equipos en la Intranet.

Comentario: Se debe considerar la identificación automática de los equipos de la

Intranet como un medio de autentificación de las conexiones provenientes de

localizaciones y equipos específicos.

Así se controlará el acceso a la Intranet, ya que todos los equipos estarán

identificados y si se produce algún incidente se podrá saber el equipo implicado

además de su localización. Si algún equipo no identificado accede a la red interna

quedará constancia de ello y se podrán tomar medidas al respecto.





Fecha de revisión:


Versión: 1.0




72

Tabla 53. Historial de Política: Desconexión automática de sesión en la Intranet.

Política: Desconexión automática de sesión en la Intranet.

Comentario: Se configurará la desconexión automática de la sesión de los

usuarios en la Intranet para evitar que alguien acceda a ésta con una sesión

iniciada por otro usuario que se ha ausentado de su equipo.

Esto se configurará para que cuando pase un cierto tiempo de inactividad

del usuario dentro de las aplicaciones y recursos de la Intranet, la sesión de éste se

cierre y se proteja de esta forma toda la información contenida en la Intranet. El

usuario deberá volver a autentificarse cada vez que pase un cierto tiempo de

inactividad, ya que su sesión expirará.





Fecha de

revisión:


Versión: 1.0




73

Políticas de seguridad para redes WIFI:

Tabla 54. Historial de Política: Controles contra código malicioso.

Política: Controles contra código malicioso.

Comentario: El objetivo de esta política es definir una serie de controles para

proteger a los sistemas de la empresa contra posibles ataques que pudieran

producirse por efectos de código mal intencionado, estos controles se definirán

según el ámbito, en primer lugar para los dispositivos móviles como IPAD, IPOD

o cualquier Smartphone, se debe realizar un chequeo de seguridad del dispositivo,

para verificar que este cuente con la última versión de software instalada,

adicionalmente se bloqueara en cualquier momento la conexión a la red si se

detecta la ejecución de algún software con comportamiento sospechoso, en lo que

respecta a los computadores personales o portátiles, se debe realizar una

comprobación del sistema para determinar que cuenta con los últimos parches de

seguridad, así como se debe realizar un chequeo del dispositivo para determinar si

dispone de software antivirus, de igual manera se monitorizará para determinar

cualquier programa con comportamiento sospechoso y se terminara la conexión a

la red de forma inmediata de darse el caso.


Fecha de revisión:


Versión: 1.0


Revisor: Responsable de seguridad de

la red

Autor: Alejandro Villanueva

74

De no cumplirse estos requerimientos se negara el acceso a la red

corporativa, adicionalmente al momento de acceder a la red se mostrara al usuario

los términos y condiciones para el uso de la red, los cuales debe aceptar para

poder hacer uso de la misma.

Política dirigida a: Departamento de Seguridad.


75

Tabla 55. Historial de Política: Controles contra códigos móviles.

Política: Controles contra códigos móviles.

Comentario: La ejecución de códigos transferibles dentro de la red WIFI

corporativa queda terminantemente prohibida, deben tomarse las medias

necesarias para bloquear cualquier ejecución de código transferible en

cualquier dispositivo conectado a la red WIFI, bloqueando el acceso a la red a

cualquier dispositivo que intente la ejecución de dichos códigos, por ende, las

actividades en la red deben encontrarse monitorizadas.

Políticas relacionadas: Controles contra códigos maliciosos.

Política dirigida a: Departamento de seguridad.



Fecha de revisión:


Versión: 1.0



la red


76

Tabla 56. Historial de Política: Controles de redes.

Política: Controles de redes.

Comentario: Los administradores de la red deben implementar medias para el

monitorización de las actividades dentro de la misma, verificando los usuarios

conectados, analizando el tráfico de la red, y aplicando medidas preventivas para

proteger la integridad del sistema bajo cualquier imprevisto.

Políticas relacionadas: Controles contra código malicioso y Controles contra

códigos móviles.




Fecha de revisión:


Versión: 1.0


Revisor: Responsable de seguridad de la red


77

Tabla 57. Historial de Política: Seguridad de los servicios de la red.

Política: Seguridad de los servicios de la red.

Comentario: Los administradores de la red deben monitorizar constantemente la

capacidad de los sistemas proveedores de servicios para evitar comprometer la

disponibilidad de los servicios de red por sobrecarga de sistemas, o la disminución

de la seguridad de la misma, se deben aplicar todas las herramientas de hardware

y software para poder mantener una alta disponibilidad de los servicios de acuerdo

a la capacidad deseada y el nivel de seguridad requerida en la misma.

Políticas relacionadas: Controles de Redes.




Fecha de revisión:


Versión: 1.0



la red


78

Tabla 58. Historial de Política: Registro de auditoría.

Política: Registro de auditoria.

Comentario: Se debe mantener un registro de todas las actividades dentro de la

red, como intentos fallidos de acceso, ataques, peticiones de archivos, bloqueos de

servicio (Denegación de Servicio), o cualquier otra excepción que ocurra dentro

de la red, para ayudar a investigaciones futuras. La aplicación de los registros y la

monitorización de actividades se enmarcara dentro de la legislación vigente en el

país que resida la sede de la empresa a aplicar la política.





Fecha de revisión:


Versión: 1.0




79

Tabla 59. Historial de Política: Uso del sistema de monitorización.

Política: Uso del sistema de monitorización.

Comentario: Se deberán revisar y analizar periódicamente los resultados de los

procedimientos de monitorización de actividades para buscar anomalías o posibles

fallas de seguridad que puedan comprometer el sistema, además para verificar el

correcto uso de la red y prevenir problemas posteriores.

Políticas relacionadas: Registro de Auditoria.




Fecha de revisión:


Versión: 1.0




80

Tabla 60. Historial de Política: Protección del registro de información.

Política: Protección del registro de información.

Comentario: Deben implementarse medias para proteger el registro de

información relacionada con las actividades de monitorización y uso de los

sistemas relacionados a estas, evitando el borrado de los archivos, la

modificación, sobre-escritura, la copia o sustracción de los archivos de forma no

autorizada.

Políticas relacionadas: Registro de Auditoria, Uso del Sistema de

Monitorización.




Fecha de revisión:


Versión: 1.0



la red


81

Tabla 61. Historial de Política: Registros del administrador y operador.

Política: Registros del administrador y operador.

Comentario: Se deben registrar todas las actividades del administrador y de los

operadores de sistemas, con la finalidad de realizar investigaciones futuras en caso

de ocurrir alguna incidencia. Se debe tomar en cuenta la fecha y hora en la que

ocurre el evento, los responsables implicados en el proceso relacionado, y la

descripción del mismo.

Políticas relacionadas: Uso del Sistema de Monitorización.




Fecha de revisión:


Versión: 1.0




82

Tabla 62. Historial de Política: Registro de fallos.

Política: Registro de fallas.

Comentario: Se debe registrar en un LOG especial debidamente protegido todos

los fallos o incidencias que ocurran en el sistema, tomando en cuenta los sistemas

de monitorización y control contra software malicioso, así como los servicios

suministrados, esto a efectos de control de calidad y del servicio y de

retroalimentación para el análisis de seguridad con la finalidad de mejorar la

seguridad de la red.

Políticas relacionadas: Registro de Auditoria, Controles de Redes, Controles

contra código malicioso y móviles.




Fecha de revisión:


Versión: 1.0



la red


83

Tabla 63. Historial de Política: Política de control de acceso.

Política: Política de control del acceso.

Comentario: en esta política se deben establecer de forma clara y concisa las

reglas para el control del acceso a los sistemas y los derechos para cada usuario o

grupos de usuario, quedando debidamente documentados y revisados tomando

como punto de partida los requerimientos de seguridad y comerciales (utilitarios).





Fecha de revisión:


Versión: 1.0



la red


84

Tabla 64. Historial de Política: Registro de usuario.

Política: Registro de usuario.

Comentario: Se deberá implementar un sistema de control de usuario (LOGIN y

PASSWORD) para el registro y des-registro del mismo, para poder otorgar a los

usuarios el acceso a los sistemas y recursos necesarios, proporcionando a cada

usuario con un ID único y una contraseña secreta.

Políticas relacionadas: Política de Control de Acceso.




Fecha de revisión:


Versión: 1.0



la red


85

Tabla 65. Historial de Política: Gestión de privilegios.

Política: Gestión de privilegios.

Comentario: Se deberá restringir y controlar la asignación de privilegios de

usuario. Los administradores de red, en base a los requisitos de cada usuario,

deben asignar los privilegios pertinentes asociados a cada usuario registrado (a

cada cuenta de usuario) para controlar el uso de los recursos del sistema y manejo

seguro de la red.

Políticas relacionadas: Política de Control de Acceso, Registro de Usuario.




Fecha de revisión:


Versión: 1.0



la red


86

Tabla 66. Historial de Política: Gestión de las claves secretas de los usuarios.

Política: Gestión de las claves secretas de los usuarios.

Comentario: El proceso de asignación de claves secretas debe ser debidamente

formalizado, se debe establecer un contrato de confidencialidad entre los usuarios

y la empresa, en el cual este se responsabilice a hacer el correcto uso de la misma,

y a mantener en secreto la contraseña que le fue asignada, en caso de las

contraseñas por grupos estos deben responsabilizarse a mantener en secreto la

contraseña de cada grupo y no traspasarla a otros grupos.

Políticas relacionadas: Registro del Usuario.




Fecha de revisión:


Versión: 1.0



la red


87

Tabla 67. Historial de Política: Revisión de los derechos de acceso del usuario.

Política: Revisión de los derechos de acceso del usuario.

Comentario: Bajo un proceso formal, los administradores de red deben revisar

los privilegios de los usuarios dentro de un determinado periodo de tiempo, en

caso de ascenso (incremento de privilegios), democión o terminación de contrato

(revocación de cuenta y terminación de privilegios), con la finalidad de mantener

en niveles óptimos la seguridad de la red corporativa.

Políticas relacionadas: Gestión de Privilegios, Gestión de las Claves Secretas de

los Usuarios.




Fecha de revisión:


Versión: 1.0



la red


88

Tabla 68. Historial de Política: Uso de claves secretas.

Política: Uso de claves secretas.

Comentario: Para aquellos usuarios a los cuales se les permita seleccionar su

clave de acceso, a aquellos que no le son asignadas por los administradores como

por ejemplo usuarios regulares, se les deberá exigir el seguimiento de unas pautas

de seguridad por defecto a tomar en cuenta en lo que respecta a la selección de

contraseñas y el manejo de las mismas. Como por ejemplo, la selección de

contraseñas complicadas (que contengan caracteres, números y letras), el

resguardo adecuado de las mismas, evitando tenerlas escritas en papeles o sitios

en los cuales puedan verse comprometidas, entre otros aspectos a tomar en cuenta

que los administradores de la red consideren pertinentes.

Políticas relacionadas: Gestión de las Claves Secretas de los Usuarios.




Fecha de revisión:


Versión: 1.0



la red


89

Tabla 69. Historial de Política: Equipo desatendido.

Política: Equipo desatendido.

Comentario: Los usuarios de equipos portátiles u dispositivos móviles deben

asegurarse que este disponga de la protección adecuada en todo momento que no

se encuentren con los mismos, haciendo uso de bloqueo de sesión o cifrado de los

archivos de los equipos, para protegerlos en caso de pérdida. De ocurrir el

extravío o robo de uno de los equipos móviles el usuario debe informar

inmediatamente a los administradores d red para que estos tomen las medidas

pertinentes.

Políticas relacionadas:




Fecha de revisión:


Versión: 1.0



la red


90

Tabla 70. Historial de Política: Uso de los servicios de red.

Política: Uso de los servicios de red.

Comentario: Se debe establecer un procedimiento formal para determinar los

servicios de red y archivos a los cuales un determinado usuario debe tener acceso,

y los procedimientos adecuados para otorgar el acceso a los servicios de red y la

debida aseguración o bloqueo de aquellos servicios a los cuales no debe tener

acceso, siendo este responsable de por cualquier uso indebido de servicios que no

le fueron otorgados.

Políticas relacionadas: Política de Control de Acceso.




Fecha de revisión:


Versión: 1.0




91

Tabla 71. Historial de Política: Computación y comunicaciones móviles.

Política: Computación y comunicaciones móviles.

Comentario: Se debe formar al personal para concientizarlo sobre los riesgos

implicados en el trabajo con dispositivos móviles, los equipos deben ser

constantemente monitorizados para asegurar que cuenta con la protección

adecuada, adicionalmente se deben implementar medidas de contingencia como

borrado de disco duro remoto o localización del equipo para casos de robo o

extravió, de esta forma se puede evitar que la seguridad de la red se comprometa

en caso de pérdida, robo o substracción de información que podría otorgarle a un

agente no autorizado las credenciales para acceder a la red corporativa.





Fecha de revisión:


Versión: 1.0




92

Tabla 72. Historial de Política: Control de vulnerabilidades.

Política: Control de vulnerabilidades.

Comentario: Se deben realizar auditorías de seguridad de la infraestructura de la

red WIFI y sus aplicaciones relacionadas, para poder localizar de forma oportuna

cualquier vulnerabilidad que pueda poner en riesgo la seguridad de la red. Una

vez identificadas las vulnerabilidades se debe elaborar un plan de acción para

solventar cualquier vulnerabilidad, partiendo por su prioridad, los responsables de

estas acciones serán los administradores de la red conjuntamente con los auditores

y los gerentes de la empresa.





Fecha de revisión:


Versión: 1.0




93

Tabla 73. Historial de Política: Reporte de eventos.

Política: Reporte de eventos.

Comentario: Todas las incidencias de seguridad deben ser reportadas

directamente a los canales gerenciales más apropiados en la brevedad posible, de

forma que se puedan diseñar los planes de acción más adecuados según la

gravedad de la incidencia. Los administradores de red deben implementar las

medidas de monitorización y control de red más pertinentes para poder capturar

cualquier excepción que ocurra dentro de la misma, de forma que se pueda

generar el reporte de incidencias de forma automática.

Políticas relacionadas: Controles de Redes, Seguridad e los Servicios de Red,

Control de Vulnerabilidades.




Fecha de

revisión:


Versión: 1.0




94

Tabla 74. Historial de Política: Reporte de las debilidades en la seguridad.

Política: Reporte de las debilidades en la seguridad.

Comentario: Se debiera requerir que todos los usuarios empleados, contratistas y

terceros de los sistemas y servicios de información tomen nota y reporten

cualquier debilidad de seguridad observada o sospechada en la infraestructura de

la red. Sin embargo se debe así mismo, notificarles que no deben tratar de probar

las debilidades encontradas en los sistemas, cualquier intento de prueba de las

vulnerabilidades encontradas puede interpretarse como un uso indebido del

sistema, así como podría causar daños en el mismo.

Políticas relacionadas: Reporte de Eventos.




Fecha de

revisión:


Versión: 1.0




95

Políticas de gestión y control de políticas:

Tabla 75. Historial de Política: Realización de revisiones y evaluaciones

Web.

Política: Realización de revisiones y evaluaciones Web.

Comentario: El objetivo de esta política es detectar brechas de seguridad

existentes en los aplicativos web, utilizando el nombre de usuario y password de

acceso. El producto será un informe de vulnerabilidades web, así como un

documento que facilite las soluciones y propuestas a aplicar para solucionar

dichas vulnerabilidades. Se utilizarán las últimas técnicas y metodologías de

seguridad disponibles.

Política dirigida a: Departamento de desarrollo.



Fecha de

revisión:


Versión: 1.0


Revisor: Responsable del departamento de seguridad

Autor: Manuel Jesús Fiz Pérez

96

Tabla 76. Historial de Política: Log Management.

Política: Log Management.

Comentario: Se definirá, diseñará, desarrollará y se hará operativa una política

de logs. Para ello se configurarán todos los dispositivos de red, sistemas

operativos, aplicaciones web y bases de datos. Los logs estarán centralizados

para un mejor acceso y gestión de los mismos.




Fecha de revisión:


Versión: 1.0




97

Tabla 77. Historial de Política: Copia en red de los Logs.

Política: Copia en red de los Logs.

Comentario: El objetivo de esta política generar una copia de los logs generados

en la red, en un servidor, para almacenar información relativa a nombres de

usuarios, direcciones IP, fecha y hora de registro, detalle de acciones realizadas,

control de accesos a recursos en función de los permisos asignados, etcétera. Se

utilizará alguna aplicación de carácter comercial para la consecución de este

propósito.




Fecha de revisión:


Versión: 1.0


Revisor: Responsable del

departamento de seguridad


98

Tabla 78. Historial de Política: Revisión de políticas de seguridad y cumplimiento

técnico.

Política: Revisión de políticas de seguridad y cumplimiento técnico.

Comentario: Esta política pretende que se cumplan el resto de políticas definidas

en este proyecto. Se elaborará un documento de seguridad, por parte del

especialista en seguridad junto con el comité de seguridad. La gerencia será

responsable de su aprobación y ejecución en la empresa. Así mismo, se definirán

sanciones para los usuarios que incumplan dichas políticas, así como para las

terceras partes que tengan una relación directa con la empresa.

Política dirigida a: Gerencia de la empresa.



Fecha de revisión:


Versión: 1.0




99

Tabla 79. Historial de Política: Auditorías de sistemas.

Política: Auditorías de sistemas.

Comentario: Esta política pretende realizar una auditoría de seguridad cada tres

meses de los sistemas informáticos, especialmente aquellos asociados al

desarrollo y publicación de la web corporativa. Se realizarán las pruebas definidas

por un especialista en seguridad, previa aprobación por escrito por parte de la

gerencia de la empresa.

Este proceso deberá generar un informe de los aspectos no coincidentes

con el nivel de seguridad definido, para, previo respaldo de la información

correspondiente, realizar las modificaciones oportunas. El software de auditoría

estará en un entorno distinto al de producción de la empresa.




Fecha de revisión:


Versión: 1.0




100

Tabla 80. Historial de Política: Monitorización de administración de sistemas.

Política: Monitorización de administración de sistemas.

Comentario: Se revisarán los permisos de ejecución de aplicación asociada al

servidor web, que se ajusten a los privilegios mínimos de uso. No se permitirá a

los operadores la realización de configuración del sistema. Se evitará el acceso

para configuración de sistemas a personal ajeno a la empresa. Se generarán

cuentas con ciertos derechos administrativos para usuarios que tengan que realizar

determinadas configuraciones de servidor.

Política dirigida a: Departamento de informática



Fecha de revisión:


Versión: 1.0




101

Tabla 81. Historial de Política: Monitorización de uso del sistema.

Política: Monitorización de uso del sistema.

Comentario: Al terminar la jornada de trabajo se apagarán todas las estaciones de

usuarios y se cerrarán adecuadamente las aplicaciones abiertas. Para cumplir este

objetivo se definirán políticas de sistema a nivel de dominio que apagarán las

estaciones de trabajo una hora después de la hora de salida de los usuarios en caso

de que alguna estación quedase encendida.

Políticas relacionadas: “Permisos de los usuarios”.

Política dirigida a: Departamento de informática



Fecha de revisión:


Versión: 1.0




102

Tabla 82. Historial de Política: Protección y respaldo de los Logs.

Política: Protección y respaldo de los Logs.

Comentario: Esta política pretende proteger los logs que, junto con la valiosa

información que almacenan, facilitan la monitorización del cumplimiento de las

políticas definidas. De esta forma, se prohíbe el borrado de cualquier fichero de

log almacenado en cualquier dispositivo y/o servidor, así como la desactivación

de cualquier log. Se generará un backup en tiempo real de los logs, que estará

centralizado físicamente, para su posterior tratamiento, dentro de un proceso de

backup adecuado. Este backup de log facilitará la información de fecha y hora de

su generación, así como el tipo de log.

Política dirigida a: Departamento de seguridad



Fecha de revisión:


Versión: 1.0




103

CAPITULO V

CONCLUSIONES

Este proyecto ha pretendido aplicar las políticas de seguridad en el

Grupo Seidor, con la finalidad de implementar controles internos para prevenir la

fuga de datos. Estas políticas han contribuido como un gran aporte para el

departamento de seguridad de Grupo Seidor, creando un antes y un después de

su elaboración y presentación de este trabajo de fin de master al departamento de

seguridad de la empresa.

El ámbito de actuación en el Grupo Seidor contempla por un lado el

comportamiento de los usuarios de la empresa respecto a los servidores web así

como de los administradores locales de las sedes en Madrid y Barcelona,

contemplando siempre las buenas prácticas en políticas de seguridad.

La contribución de estas políticas que se aplicaron en este trabajo de fin

de master ha permitido al Grupo Seidor evaluar tecnologías basadas en software

y hardware como por ejemplo: NAP-ISE de los fabricantes Microsoft y Cisco

respectivamente.

La contribución que se ha logrado para las políticas de protección de la

Intranet, se centró en servidores, aplicaciones, usuarios y administradores del

Grupo Seidor. Las políticas de seguridad para redes wifi se ocuparon de

proteger un área que ofrecía mayores posibilidades de fuga de datos en el

Grupo Seidor. Finalmente, se dedicó un área a la revisión de las propias

políticas de seguridad así como el cumplimiento del personal responsable de

TI en Madrid y Barcelona.

La aplicación de estas políticas en el Grupo Seidor es una gran mejora

en su infraestructura de red local y permitirá una mejor visión de la situación

actual de los activos de red y una mayor protección de los mismos ante la

amenaza siempre constante de fuga de datos corporativos.

104

CAPITULO VI

TRABAJOS FUTUROS

Las políticas desarrolladas en este trabajo, han de crear un precedente en

la organización Grupo Seidor, es por ello que a través del departamento de

seguridad de la compañía se ha pedido su aplicación en un corto plazo, para

ayudar a la protección y mitigación de la fuga de información. Enfocados

específicamente en el departamento de desarrollos de negocios que en los

últimos años ha sufrido la pérdida y fuga de material altamente confidencial

que han ocasionado la pérdida contratos y negocios millonarios.

Esto ha traído como consecuencia que el crecimiento programado de la

organización ha tenido un atraso en su desarrollo, pero la aplicación a corto

plazo de estas políticas tendrá un aporte muy positivo en el desarrollo de la

organización.

105

APENDICES

106

APENDICE I

BIBLIOGRAFÍA

1.- Cresson Wood, Charles. 2003. Políticas de Seguridad Informática – Mejores

Prácticas Internacionales. Houston: MetIQ, Inc.

2.- Coite, Angélica y romero Hugo. S.f. “Auditoría de Sistemas y políticas de

Seguridad Informática”. www.monografias.com (Consultada: 04/01/2011)

3.- J. Cano, Jeimy. 2000. “Pautas y recomendaciones para elaborar Políticas de

seguridad Informática (PSI)”. www.criptored.upm.es (Consultada: 12/01/2011)

4. - ISO/IEC 27002:2005 Information technology — Security techniques — Code

of practice for information security management. First Edition 2005-06-15.

5.- Microsoft Technet. “Network Access Protection”.

http://technet.microsoft.com/en-us/network/bb545879 (Consultada: 15/03/2011)

http://www.monografias.com/

http://www.criptored.upm.es/

http://technet.microsoft.com/en-us/network/bb545879

107

APENDICE II

ANTECEDENTES

Antecedente 1:

Título: Metodología para la incorporación de medidas de seguridad en sistemas

de información de gran implantación: confianza dinámica distribuida y regulación

del nivel de servicio para sistemas y protocolos de Internet.

Autor: Muñoz Esteban, Juan Jesús

Universidad: UPM

Departamento: Ingeniería en Sistemas Telemáticos

Fecha de Lectura: 2004

Resumen:

Los orígenes de Internet y su propio talante han conducido a un modelo de

servicio un tanto confiado, que arrastra una imagen de inseguridad. Se dispone de

multitud de tecnologías de demostrada solvencia técnica, que resuelven

problemáticas en ámbitos concretos, pero que no se integran en un modelo global

de seguridad. A la utilización de la red para difundir con excesiva rapidez

elementos dañinos, como los virus, se suman de forma creciente otros

comportamientos abusivos, como el envío masivo de correo electrónico con fines

comerciales (spam) o incluso fraudulentos (phishing). Estos excesos en el envío

de mensajes provocan despilfarros de recursos y afectan a la productividad de los

usuarios finales, quienes se procuran herramientas para paliar su problema

localmente.

Todas las solicitudes de servicio se tratan por igual, sin más limitación que la

propia capacidad de los equipos y enlaces de comunicaciones, sin tener en cuenta

la reputación del interlocutor, aceptando identidades fácilmente usurpables. Esta

tesis plantea cubrir el espacio entre la autentificación fehaciente del cliente, que

requiere despliegues costosos y no inmediatos, y la confianza ciega en cualquier

usuario o equipo atribuida al mero hecho de estar conectado a la red y exhibir una

108

dirección. Cada servidor será capaz de valorar la confianza que le merecen sus

clientes en función de las experiencias acumuladas directamente o recogidas de

terceros. Esa confianza dependerá de la fiabilidad con que se les pueda vincular a

sus mensajes, y su adecuada utilización del sistema, determinada por la

exposición de un volumen suficiente de sus mensajes y solicitudes al análisis de

los usuarios finales y de otras herramientas complementarias.

Resulta imprescindible poder atribuir cada mensaje al remitente correcto. Pero

si sólo se conocen parámetros de la propia red, su usurpación permitiría inhabilitar

cualquier medida, por lo que se necesitan limitaciones preventivas en el consumo

de recursos. Se plantea que los clientes que deseen alcanzar un mayor crecimiento

de su confianza y carezcan de credenciales puedan, partiendo de un intercambio

inicial de claves y encadenando autenticaciones oportunistas, graduar el coste que

deseen asumir para minimizar las restricciones que se les apliquen. Para ello el

servidor enviará los cambios en forma de retos, y el cliente contribuirá a aumentar

la fiabilidad empleando tiempo en su resolución. Este mecanismo reduce además

la rentabilidad de posibles ataques.

La confianza se proyectará en una política de seguridad no orientada a la

concesión o denegación del acceso a datos o al uso de los recursos, sino a la

gradación del nivel de servicio permitido. Éste variará dinámicamente y de forma

consensuada entre la denegación conjunta y un máximo global. Se propone un

modelo dinámico y distribuido, descrito mediante la "lógica subjetiva" de Audum

Jøsang, que permite representar los conceptos de confianza e incertidumbre en un

valor (wAc(ti)) denominado opinión. La opinión, calculada en base al

comportamiento reciente del cliente, resume la confianza que merece, y de ella se

calculan las restricciones que procedan. Además se puede intercambiar con

terceros, constituyéndose federaciones en las que se apliquen políticas comunes

de contención que acoten el consumo global de recursos.

El álgebra asociada permite ponderar las opiniones ajenas y previas, y

combinarlas mediante las operaciones denominadas recomendación y consenso

109

bayesiano. Además se introducen en el modelo, también con este mecanismo, los

resultados de herramientas externas como los filtros, listas negras, etc. El

comportamiento global del sistema se corresponde a la amortiguación que ejerce

un filtro paso bajo con un tope limitador. En Dinámica de Sistemas este tipo de

sistema realimentado de primer orden corresponde al modelo de crecimiento

logístico, utilizado para estudiar epidemias, y se caracteriza por la forma

sigmoidal que delimita la velocidad de propagación o difusión, siendo inocuo para

usuarios asiduos. Los ámbitos de aplicación de esta propuesta son muy amplios, y

en general la gestión de despliegue y posterior administración es mínima,

manteniendo compatibilidad con clientes no modificados. Se propone su

utilización como medida preventiva y complementaria en la lucha contra el spam

en Internet, la priorización de la difusión de contramedidas o la prevención de

ataques de denegación de servicio en web services, entre otras posibilidades.

Fuente:

Archivo Digital de la UPM3

3 2011. “Archivo Digital UPM” “http://oa.upm.es/323/”. Consultada: (23/03/2011)

110

Antecedente 2:

Título: UNA NUEVA METODOLOGÍA PARA EL ESTUDIO DEL

CUMPLIMIENTO DE POLÍTICAS DE SEGURIDAD EN SISTEMAS DE

INFORMACIÓN

Autor: JACOB TAQUET, EDUARDO

Universidad: PAÍS VASCO/EUSKAL HERRIKO UNIBERTSITATEA

Departamento: ELECTRONICA Y TELECOMUNICACIONES

Fecha de Lectura: 13/09/2001

Resumen:

La concepción clásica de seguridad de la información incluye amenazas a estas

tres características de la información: confidencialidad, Disponibilidad e

Integridad.

En la actualidad, existe gran cantidad de incidentes de seguridad que atacan a

alguna de estas características. Para listar las interacciones permitidas entre

sujetos y objetos se emplean las políticas de seguridad. Dicho documento puede

ser implementado por las empresas siguiendo técnicas propias, metodologías

estandarizadas o incluso en algunos casos, de manera intuitiva.

El problema que surge es el de averiguar si la infraestructura del sistema de

información es capaz de soportar (en el sentido de hacer cumplir) una determinada

política de seguridad.

Para dar respuesta a este problema, en el estado del arte se realiza una revisión,

por un lado de las técnicas y metodologías para el estudio y evaluación de la

seguridad y por otro de las técnicas de securización. Se estudian los puntos fuertes

y los débiles de cada una de estas técnicas. Ninguna de éstas da por sí sola

respuesta al problema. En esta tesis se realiza un trabajo que tiene por resultado:

111

* Un modelo y metodología que posibilitan el estudio de la capacidad de la

infraestructura hardware y software de un sistema de información para soportar

una determinada política de seguridad, incluyendo en esta capacidad, tanto la

calidad del elemento como la importancia de cada frase de la política de

seguridad.

* Un mecanismo para permitir la visualización de las relaciones e interacciones (a

veces ocultas) de elementos entre sí y con elementos de la política de seguridad,

descubriendo qué elementos son más críticos, desde el punto de vista de la

seguridad, en la arquitectura de la solución.

* Una técnica para evaluar la calidad de los elementos que constituyen un sistema

de información.

Fuente:

Base de datos de Tesis Doctorales TESEO4

4 2011. “Tesis Doctorales TESEO” https://www.educacion.es/teseo/irGestionarConsulta.do.

Consultada: (23/03/2011)

https://www.educacion.es/teseo/irGestionarConsulta.do

112

Organigrama de la Empresa:

Figura 1. Organigrama de la Empresa.

Cisco 2Q10 Global Threat Report 1

Key Highlights

Eastern Europe encountered the highest rate of web-based malware in 2Q10, followed •

by South America and China;

IPS SQL injection signature firings increased substantially in 2Q10, coinciding with outbreaks •

of SQL-injection-compromised websites;

Asprox SQL injection attacks made a reappearance in June of 2010, after nearly six months •

of inactivity;

Gumblar-compromised websites continued to be the most frequently encountered sources •

of web-based malware in 2Q10;

7.4 percent of all web-based malware encounters in 1Q10 resulted from search engine •

queries and nearly 90 percent of all Asprox encounters in June of 2010 were the results

of links in search engine results pages;

Companies in the Pharmaceutical and Chemical vertical were the most at risk for web •

malware encounters, experiencing a heightened risk rating of 400 percent in 1Q10 and

543 percent in 2Q10;

Increases in peer-to-peer (P2P) activity were observed across the top three P2P networks •

(eDonkey, Gnutella, and BitTorrent) throughout the first quarter of 2010, with the strongest

increase in March of 2010;

Continuous high saturation in 2Q10, coupled with recent P2P malware developments, •

suggest that peer-to-peer file shares are becoming increasingly favored by users

and malware attackers alike.

Cisco 2Q10 Global Threat Report


Encounter Rates

The number of unique malware hosts and malicious URLs remained fairly constant month-over-month

during the second quarter of 2010. This is a significant development in terms of web-based malware,

as it marks the first time since tracking began in 2007 that the number of malware hosts and URLs has

remained relatively flat over an entire quarter.

Despite the 2Q10 leveling of malicious URLs and malware domains, the average daily encounter rate

increased month-over-month throughout the quarter.

Exploits

65 percent of all

web-based malware

encounters were blocked

prior to exploit code or

involved encounters

which did not include

exploit code. Of exploits

that are encountered,

those targeting Adobe

Reader/Acrobat, Sun

Java, and Adobe Flash

were the three most

common during the

first half of 2010.

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Jan Feb Mar Apr May Jun

Figure 1 Unique Web-Based Malware Hosts, 1H10Source: Cisco ScanSafe

Cisco Security

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

0Jan Feb Mar Apr May Jun

Figure 2 Unique Web-Based Malware URLs, 1H10Source: Cisco ScanSafe

Cisco Security

Unfortunately, exposure is not necessarily

a direct result of the quantity of malware hosts/

URLs. Instead, the quality of traffic driving efforts

(for example, black hat search engine optimization

and social engineering) to those malware

hosts/URLs bears more of an impact on overall

encounter rates.

Encounters with web-based malware increased

month-over-month in the first quarter with a

significant increase in March of 2010. That increase

was followed by a drop in encounters in April of

2010— likely the result of a series of concerted

takedown efforts from various sources aimed at the Waledac, Mariposa, and Zeus botnets. In June of

2010, the average daily encounter rate had increased to the same level observed in March of 2010.

65 percent of all web-based malware encounters were blocked prior to exploit code or involved

encounters which did not include exploit code. Of exploits that are encountered, those targeting Adobe

Reader/Acrobat, Sun Java, and Adobe Flash were the three most common during the first half of 2010.

0%

20%

40%

60%

80%

100%

120%

140%

Apr May Jun

Figure 3 Average Daily Encounter Rates, 2Q10Source: Cisco ScanSafe

Cisco Security


Malware Prevalence

Gumblar comprised 5 percent of

all web-based malware in 2Q10

and 11 percent of all web-based

malware in 1Q10, with the highest

concentration during March of 2010

(17 percent).

The Vertical Risk

Companies in the Pharmaceutical

and Chemical vertical were the

most at risk for web-based malware

encounters, experiencing a heightened

risk rating of 543 percent in 2Q10, up from 400 percent in 1Q10. Other higher

risk verticals in 2Q10 included Energy, Oil, and Gas (446 percent), Education (157 percent),

Government (148 percent), and Transportation and Shipping (146 percent).

0% 100% 200% 300% 400% 500% 600%

Pharmaceutical and Chemical

Energy, Oil, and Gas

Education

Government

Transportation and Shipping

Charities and Non-Governmental Organizations

Banking and Finance

Food and Beverage

Real Estate and Land Management

Industrial

Healthcare

Agriculture and Mining

Engineering and Construction

Travel and Leisure

Manufacturing

Legal

Clubs and Organizations

HVAC, Plumbing, and Utilities

Media and Publishing

Retail and Wholesale

Aviation and Automotive

IT and Telecom

Professional Services

Figure 5 Vertical Risk: Web-Based Malware, 2Q10Source: Cisco ScanSafe

Cisco Security

Cisco Security

Exploit.JS.Gumblar

Trojan.JS.Redirector.cq

PSW.Win32.Infostealer.bnkb

Mal/GIFIframe-A

JS.Redirector.AT

Worm.Win32.VBNA.b

Backdoor.Win32.Alureon

JS.Redirector.BD

Mal/Iframe-F

Backdoor.TDSSConf.A

1.9%

5.4%

5.3%

3.0%2.4%

2.2%

2.2%

2.1%

2.0%

2.0%

Figure 4 Top Ten Web-Based Malware, 2Q10Source: Cisco ScanSafe

Cisco Security


SQL Injection Attacks Resume in 2Q10

The following chart reflects the top three Cisco® IPS signature events for potential SQL-injection-related

attacks during the first half of 2010.

*SQL Query in HTTP Request detects the presence of encoded words that are indicative of SQL injection attacks. **Generic SQL Injection v1 and Generic SQL Injection v2 detect SQL keywords in HTTP arguments

Interestingly, a substantial increase in SQL injection events can be observed beginning in late March and

early April of 2010 and extending throughout the remainder of the second quarter. This elevation in SQL

injection IPS events coincides with a corresponding increase in website compromises brought on by

SQL injection attacks during the same period.

The 2Q10 increase in SQL injected websites culminated with a June 2010 reappearance of Asprox.

The most common cause of website compromise in mid-2008, Asprox (and all other SQL injection attacks)

progressively declined throughout 2009, with Asprox completely absent in the first quarter of 2010.

Search engine results pages (SERPs) play a significant role in driving traffic to compromised websites.

In 1Q10, 7.4 percent of all web-based malware encounters resulted from search engine queries. Over

90 percent of all Asprox encounters in June of 2010 were the result of SERP encounters brought on by

legitimate search engine queries.

Vulnerable SQL servers were certainly not the only asset sought after by attackers in 2Q10.

Observation of Cisco IPS signature event firings indicate that reconnaissance sweeps (which could

be indicative of network mapping) also increased through the second quarter.

The TCP SYN Host Sweep signature fires when a series of TCP SYN packets have been sent from

one single host to a number of different hosts. Typically, this behavior should not be observed from

sources outside the local network but are normal behaviors for sources from within the local network

(recommended filters are to exclude internal networks as sources).

0

1000

2000

3000

4000

5000

6000

7000

Figure 6 Top Three SQL Injection Events, 1H10Source: Cisco IPS

SQL Query in HTTP Request*

Generic SQL Injection v1**

Generic SQL Injection v2**

1/1/2010

1/8/2010

1/15/2010

1/22/2010

1/29/2010

2/5/2010

2/12/2010

2/19/2010

2/26/2010

3/5/2010

3/12/2010

3/19/2010

3/26/2010

4/2/2010

4/9/2010

4/16/2010

4/23/2010

4/30/2010

5/7/2010

5/14/2010

5/21/2010

5/28/2010

6/4/2010

6/11/2010

6/18/2010

6/25/2010

Cisco Security

What is SQL Injection?

The SQL language is

used to manage the data

contained in relational

databases and administer

the SQL servers that

house that data. A SQL

injection attack uses

malformed SQL

statements in an attempt

to override intended

behavior and cause the

SQL server to act upon

the statement in an

unintended fashion.

SQL servers that do not

properly validate input

data or sanitize output

data can be vulnerable

to various types of SQL

injection attacks.

Successful attacks can

lead to a range of possible

compromise conditions,

including the alteration

of contents of a database,

sensitive information

disclosure, or the

control of a SQL server.


ICMP Network Sweep with Echo is a medium-severity signature that triggers when IP datagrams are

received directed at multiple hosts on the network with the protocol field of the IP header set to 1 (ICMP)

and the type field in the ICMP header set to 8 (Echo Request). Some network management tools provide

network mapping capabilities which may be at least partially accomplished via a ping sweep of the

network address space, resulting in a benign trigger.

Multiple Rapid SSH Connections fire when there are rapid SSH connection from the same source

to the same destination. Legitimate automated process using SSH can result in a benign trigger. The

recommended action is to filter systems invoking automated SSH connections as sources for this alarm.

Wormable Risks

Increases in P2P activity observed from the end of the first quarter and persisting through the second

quarter correlate with an overall increase in the number (and severity) of malware that uses P2P networks

as a means of propagation.

Cisco Intrusion Prevention System

The Cisco Intrusion

Prevention System (IPS)

provides protection against

over 30,000 known

threats with Cisco Global

Correlation to dynamically

recognize, evaluate, and

stop emerging Internet

dangers. Global Correlation

combines the inspection

capability of new and

existing signatures

with intelligence from

the Cisco SensorBase

Network. Network

participation and

reputation are the two

core components of

Global Correlation.

Network participation

enables IPS devices to

send data such as

signature IDs, attacker

ports and addresses,

reputation scores, and

risk ratings to Cisco

SensorBase. Reputation

provides an IPS with

a probability that a

given IP address is

malicious. IPS devices

interact with the Cisco

SensorBase Network

to send network

participation data and

receive reputation data.

0

20000

40000

60000

80000

100000

120000

140000

160000

180000

1/1/2010 2/1/2010 3/4/2010 4/4/2010 5/4/2010 6/4/2010

Figure 7 Top Three IPS Signature Event Firings, 1H10Source: Cisco IPS

TCP SYN Host SweepICMP Network Sweep with EchoMultiple Rapid SSH Connections

200000Cisco Security

1/1/2010 2/1/2010 3/1/2010 4/1/2010 5/1/2010 6/1/2010

Figure 8 Top Three P2P Events, 1H10Source: Cisco IPS

0

20000

40000

60000

80000

100000

120000

140000

160000

BitTorrent Tracker QueryGnutella Upload Download Stream UDP eDonkey Activity

180000Cisco Security


North America

China

South America

EuropeEastern Europe

Africa

Nordic Region

Asia Pacific

Middle East

Figure 9 Relative Exposure Risk for Web-Based Malware by RegionSource: Cisco IronPort

Cisco Security

14%9%

33%

11%

4%6%

9%

6%

9%

By dropping malware to known P2P file shares, attackers can make any threat ‘wormable’ and thus

enable rapid propagation. Recent variants of the Palevo family of malware include P2P infection along with

Instant Messaging (IM) and autorun spread. Worm.Win32.VBNA.b, a top ten threat during 2Q10, combines

autorun spread with a file-infecting virus in order to effect penetration within an enterprise.

The continued high prevalence of autorun worms in general indicates that such methods are popular

with attackers—and for good reason. P2P enables wide global seeding of the malware, an ideal method

for installing initial droppers or more general purposed malware. Conversely, autorun worms provide an

effective means to propagate more reconnaissance-focused malware within a particular enterprise.

In June of 2010, security researchers at Belarus anti-virus firm VirusBlokAda (VBA) discovered rootkit-

enabled malware that was exploiting a zero-day Windows Shell vulnerability (Microsoft Security Advisory

2286198) which enables malformed .LNK files to execute specified files automatically. The malware

employing that exploit was part of a targeted attack believed to have been designed to steal SCADA

design documents.

Whether via autorun or malformed .LNK files, this method of making a threat wormable can enable

attackers to gain access to systems that might not otherwise be connected to the Internet or even to the

wider network. Understanding normal behavior for certain types of traffic (for example, by monitoring P2P

IPS events) can help identify traffic changes that could point to potential malware activity.

Geographic Distribution of Risk

Cisco IronPort SenderBase aggregates information from over 100,000 distinct sources across the globe.

Regional risk assessment is based on a uniform sampling of data derived from participating/reporting

appliances located in 78 countries. A risk rating is derived by first calculating the rate of malicious web

traffic compared to legitimate traffic, based on the point of origination of the requesting appliance.

That result is then compared to the results for other locales to derive the final relative exposure risk

for a particular country or region.


Results of the sampling indicate the regions which were most at risk for encountering web-based malware

during 2Q10 were Eastern Europe (33 percent), South America (14 percent), and China (11 percent). The

Nordic Region experienced the lowest level of risk, at 4 percent compared to other geographical areas.

However, these results were somewhat influenced by specific countries within a particular region that

exhibited an abnormally higher or lower risk compared to other countries in that same region.

An example of this is Kazakhstan, which exhibited a 37 percent relative exposure rate among Eastern

European countries, 2.5 times that of the second highest country in the region.

South America was largely domi-

nated by two countries, Venezuela

(41 percent) and Chile (35 percent)

followed by Mexico at 10 percent.

Among countries in Europe, the

spread was less dramatic with the

UK at 29 percent, Spain second

highest at 19 percent and France

third at 11 percent.

When viewed at an individual

country level, the regional bias remains

evident, as seen in Figure 11.

15%

37%14%

13%

8%

Figure 10 Top Five Relative Exposure Risk for Web-Based Malware, Eastern Europe 2Q10 Source: Cisco IronPort

Cisco Security

Russian Federation

Kazakhstan

Bosnia andHerzegovina

Ukraine

Azerbaijan

Figure 11 Top Ten Countries Relative Exposure Risk for Web-Based Malware, 2Q10Source: Cisco IronPort

Cisco Security

9%4%

7%

8%

21%

7%

4%2%

Russian Federation

Kazakhstan

Bosnia andHerzegovina

Moldova

China

2%

Mexico

Azerbaijan

Ukraine8%

Venezuela

Chile

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco, the Cisco logo, and Cisco Systems are registered trademarks or trademarks of Cisco and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1002R)

For more information

on Cisco SIO, visit

www.cisco.com/go/sio.

http://tools.cisco.com/security/center/home.x

A Forrester Consulting Thought Leadership Paper Commissioned By Microsoft And RSA, The Security Division Of EMC

The Value Of Corporate Secrets How Compliance And Collaboration Affect Enterprise Perceptions Of Risk

March 2010

Forrester Consulting

The Value Of Corporate Secrets

Page 1

Table Of Contents

Executive Summary ................................................................................................................................................................................. 2

Secrets Comprise Two-Thirds Of The Value Of Firms’ Information Portfolios ........................................................................ 3

Compliance, Not Security, Drives Security Budgets ......................................................................................................................... 7

Firms Focus On Preventing Accidents, But Theft Is Where The Money Is ................................................................................. 8

The More Valuable A Firm’s Information, The More Incidents It Will Have .......................................................................... 10

CISOs Do Not Know How Effective Their Security Controls Are ............................................................................................... 12

Conclusions And Recommendations ................................................................................................................................................ 12

Key Recommendations ......................................................................................................................................................................... 13

Appendix A: Methodology .................................................................................................................................................................. 14

Appendix B: Supplemental Material .................................................................................................................................................. 17

Appendix C: Endnotes .......................................................................................................................................................................... 17

© 2010, Forrester Research, Inc. All rights reserved. Unauthorized reproduction is strictly prohibited. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change. Forrester®, Technographics®, Forrester Wave, RoleView, TechRadar, and Total Economic Impact are trademarks of Forrester Research, Inc. All other trademarks are the property of their respective companies. For additional information, go to www.forrester.com. [1-EG6EJT]

About Forrester Consulting Forrester Consulting provides independent and objective research-based consulting to help leaders succeed in their organizations. Ranging in scope from a short strategy session to custom projects, Forrester’s Consulting services connect you directly with research analysts who apply expert insight to your specific business challenges. For more information, visit www.forrester.com/consulting.



Page 2

Executive Summary

In November 2009, Microsoft and RSA, the security division of EMC, commissioned Forrester Consulting to assess the data security practices of North American, European, and Australian enterprises. We sought to understand: 1) the value of sensitive information contained in enterprise portfolios; 2) the security controls used to protect this information; 3) the drivers of information security programs; and finally, 4) the cost and impact of enterprise data security incidents. For this report, Forrester conducted 305 in-depth surveys with IT security decision-makers to understand how enterprises value and protect their enterprise information portfolios.

Key Findings Enterprises’ chief information security officers (CISOs) face increasing demands from their business units, regulators, and business partners to safeguard their information assets. Security programs protect two types of data: secrets that confer long-term competitive advantage and custodial data assets that they are compelled to protect. Secrets include product plans, earnings forecasts, and trade secrets; custodial data includes customer, medical, and payment card information that becomes “toxic” when spilled or stolen. We found that enterprises are overly focused on compliance and not focused enough on protecting their secrets. Our key findings are the following:

• Secrets comprise two-thirds of the value of firms’ information portfolios. Despite the increasing mandates enterprises face, custodial data assets aren’t the most valuable assets in enterprise information portfolios. Proprietary knowledge and company secrets, by contrast, are twice as valuable as the custodial data. And as recent company attacks illustrate, secrets are targets for theft.

• Compliance, not security, drives security budgets. Enterprises devote 80% of their security budgets to two priorities: compliance and securing sensitive corporate information, with the same percentage (about 40%) devoted to each. But secrets comprise 62% of the overall information portfolio’s total value while compliance-related custodial data comprises just 38%, a much smaller proportion. This strongly suggests that investments are overweighed toward compliance.

• Firms focus on preventing accidents, but theft is where the money is. Data security incidents related to accidental losses and mistakes are common but cause little quantifiable damage. By contrast, employee theft of sensitive information is 10 times costlier on a per-incident basis than any single incident caused by accidents: hundreds of thousands of dollars versus tens of thousands.

• The more valuable a firm’s information, the more incidents it will have. The “portfolio value” of the information managed by the top quartile of enterprises was 20 times higher than the bottom quartile. These high-value enterprises had four times as many security incidents as low-value firms. High-value firms are not sufficiently protecting data from theft and abuse by third parties. They had six times more data security incidents due to outside parties than low-value firms, even though the number of third parties they work with is only 60% greater.

• CISOs do not know how effective their security controls actually are. Regardless of information asset value, spending, or number of incidents observed, nearly every company rated its security controls to be equally effective — even though the number and cost of incidents varied widely. Even enterprises with a high number of



Page 3

incidents are still likely to imagine that their programs are “very effective.” We concluded that most enterprises do not actually know whether their data security programs work or not.

The sections that follow explain our findings in detail.

Secrets Comprise Two-Thirds Of The Value Of Firms’ Information Portfolios

Enterprise information portfolios contain everything from cardholder details and customer records to unstructured documents that contain intellectual property. We identified two kinds of information that have clear and tangible value. Proprietary company secrets generate revenue, increase profits, and maintain competitive advantage. In addition, custodial data such as customer, medical, and payment card information has value because regulation or contracts make it toxic when spilled and costly to clean up. We explain each below.

Secrets refer to information that the enterprise creates and wishes to keep under wraps. Secrets tend to be messily and abstractly described in Word documents, embedded in presentations, and enshrined in application-specific formats like CAD. Secrets that have intrinsic value to the firm are always specific to the enterprise’s business context. An interested party could cause long-term competitive harm if it obtains these secrets. Keeping proprietary knowledge away from competitors is essential to maintaining market advantage (see Figure 1).

Figure 1 Secrets Versus Custodial Data

Source: Forrester Research, “Selecting Data Security Technologies,” December 2009.



Page 4

Companies in knowledge-intensive industries such as aerospace and defense, electronics, and consulting generate large amounts of confidential intellectual property that present barriers to entry for competitors. Unlike with toxic data spills, failures to protect secrets are almost never made public. And in January 2010, a major search engine revealed that Chinese attackers compromised its computers and stole valuable intellectual property.1

By contrast, legislation, regulation, and contracts compel enterprises to protect custodial data. Mandates that oblige enterprises to be good custodians include contractual obligations like the Payment Card Industry Data Security Standard (PCI-DSS) and data breach and privacy laws.

Custodial data has little intrinsic value in and of itself. But when it is obtained by an unauthorized party, misused, lost, or stolen, it changes state. Data that is ordinarily benign transforms into something harmful. When custodial data is spilled, it becomes “toxic” and poisons the enterprise’s air in terms of press headlines, fines, and customer complaints. Outsiders, such as organized criminals, value custodial data because they can make money with it. Custodial data also accrues indirect value to the enterprise based on the costs of fines, lawsuits, and adverse publicity.

Examples of custodial data include customer personally identifiable information (PII) attributes like name, address, email, and phone number; government identifiers; payment card details like credit card numbers and expiration dates; and medical records and government identifiers like passport number and Social Security Number. Many well-known firms have graced the front pages of major newspapers with toxic data spills.

Secrets Are Much More Valuable Than Custodial Data Catastrophic toxic data spills are dramatic and expensive, and they garner the most headlines. But for most enterprises, secrets are more valuable than custodial data. For this survey, we asked respondents to identify the five most valuable assets in their information portfolios out of 17 possible types of information ranging from sales forecasts to cardholder data. For purposes of simplicity, we constrained the maximum value to $1 million. On average, enterprises valued their top five assets at $2.7 million in aggregate. Significantly, two-thirds of the value comes from secrets, not custodial data (see Figure 2).



Page 5

Figure 2 Enterprises’ Information Portfolios Are Worth $2.7 Million, 62% Of Which Derives From Secrets

Base: 305 senior-level IT security decision-makers

Source: A commissioned study conducted by Forrester Consulting on behalf of RSA and Microsoft, November 2009

Earnings and financial information is the most valuable single data type, worth $297,000 on average against a maximum possible value of $1 million. Bills of materials are valued lowest, at $55,492 (see Figure 2).

We found significant differences between verticals. Enterprises in highly knowledge-intensive industries like manufacturing, information services, professional, scientific and technical services, and transportation accrue between 70% and 80% of their information portfolio value from secrets. By contrast, healthcare firms and governmental entities are nearly exactly the opposite. Three-fifths or more of the value of their information assets are custodial data assets (see Figure 3).

$55,492

$89,836

$106,639 $108,033

$126,230 $129,426

$171,557

$160,902$147,787

$174,590$190,246

$170,820

$226,393

$296,967

$234,016

$270,574

$0

$50,000

$100,000

$150,000

$200,000

$250,000

$300,000

$350,000

0% 10% 20% 30% 40% 50% 60% 70%

Mean value

Percent of customers who cited a type of IP as “important” or “very important”

PII about customers

Earnings and financial info

Customer contact info

Financial models

Competitive analyses Plans for new products and services

Proprietary research

Source code

Sales pipelines and forecasts

Bills of materials

Clinical trial info

Product schematics and CAD drawings

Pricing lists

Med records and PHI

Mergers and acquisition data

Cardholder data related to compliance w/ PCI



Page 6

Figure 3 Knowledge Industries Derive 70% Of Their Information Value From Secrets



Conclusion: Enterprise secrets are an underappreciated and underprotected information asset. Poor custodianship of customer and cardholder data by companies results in high-profile toxic data spills. But in most industries, this is only one-third of the value at risk. Two-thirds of enterprises’ information portfolio value comes from the secrets they create. As the recent industrial espionage attack on a large search engine company illustrates, the threat landscape has not changed, but our perception of it has.2 Targeted zero-day attacks are routine, particularly against government agencies and in the aerospace and defense sectors. What is new is that we are now seeing headlines about it. This search engine’s admission that it lost some of its secrets in the recent attack shows that securing trade secrets deserves just as much attention as the toxic stuff.

34%

41%

62%

62%

67%

67%

69%

71%

74%

66%

59%

38%

38%

33%

33%

31%

29%

26%

Health care and social assistance

Public administration

Retail, accomoodation, and food services

Finance and insurance

Manufacturing

Utilities

Wholesale, transportation, and warehousing

Information

Professional, scientific, and technical services

Secrets Custodial Data



Page 7

Compliance, Not Security, Drives Security Budgets

In the past five years, “compliance” of all types has become the primary driver of data security programs. Nearly 90% of enterprises we surveyed agreed that compliance with PCI-DSS, data privacy laws, data breach regulations, and existing data security policies is the primary driver of their data security programs.3

A significant percentage of enterprise budgets (39%) is devoted to compliance-related data security programs (see Figure 4). When we dug deeper, Forrester found that while all types of compliance have an influence on budgets, compliance with internal security policies is slightly more likely to move budgets than the statutory and regulatory kind. Nearly 70% of enterprises said that compliance with internal security policies had caused them to spend more time, money, or effort protecting their data. Slightly lower percentages cited compliance with statutes and regulations (62%) and contractual obligations like PCI-DSS (60%). No doubt all of these factors are mutually reinforcing.4

Conclusion: Companies are underinvesting in programs for protecting their secrets. Interestingly, the percentage of budget spent on compliance programs is nearly identical to the percentage of enterprise information value that can be attributed to custodial data (38%). Only 41% of enterprise data security budgets were spent on securing non-compliance-related types of sensitive corporate information, compared with 62% of the overall information portfolio’s total value.

Figure 4 Compliance Drives Budgets, But Enterprises Underinvest In Other Data Security Areas



Compliance driven

projects and technology

39%

Non-compliance-

related initiatives to

protect sensitive corporate

information41%

Other14%

Don't know6%

“Please indicate how your IT security budget for 2010 is allocated.”



Page 8

Firms Focus On Preventing Accidents, But Theft Is Where The Money Is

Enterprise perceptions of risk — the types of data security incidents that are most likely, and their magnitude — show that enterprise perceptions are oriented toward preventing accidents. We asked security decision-makers to identify the likelihood of 13 specific sources of data security incidents, such as misplacement of an employee device, theft by a privileged insider, an outsourced call center, and a variety of other sources. We also asked respondents to count the number of incidents they had actually experienced in the past two years.

Enterprise perceptions of incident likelihood were backed up by the incidents they experienced. A majority of enterprises felt that employee-related accidents were the most likely sources. Theft or misplacement of an employee device was seen as likely or extremely likely by 58% of respondents, while the risk of accidental leakage by an employee was seen as nearly as risky (57%). And indeed, the top three actual incidents reported were all employee-related accidents. Enterprises lost, on average, 11 company-owned smartphones and seven laptops during the past two years. Employees accidentally emailed or posted sensitive information five times. Of the roughly 40 incidents, these three types comprised two-thirds of the total count (see Figure 5).

Figure 5 Employee Toxic Data Accidents Represent 57% Of Incidents . . .



0.69

0.80

0.94

1.05

1.06

1.55

1.66

2.62

3.00

3.56

4.82

6.81

11.30

An IT administrator abused privileges and stole data

A supply chain or business partner abused their privileges and obtained data they should not have had access to

An outside business partner lost sensitive information via other means

A rogue employee stole sensitive company documents

An outside attacker compromised a server and stole data

IT operations lost an unencrypted backup tape or drive

A terminated employee stole information because they had not been adequately de-provisioned

An outside business partner lost a laptop containing sensitive information

A rogue employee used their privileges to access sensitive company documents that they had no business reason to …

A customer service representative inappropriately accessed customer records

An employee accidentally e-mailed or posted sensitive information

An employee lost a laptop containing sensitive information

An employee lost a smartphone

“Over the last 2 years, has your enterprises experienced any of the following kinds of data leak incidents? Please indicate the number of incidents. If you have not had any incidents for a particular type, please enter ‘0’.”

22.9 out of 39.9 incidents

58% represent employee-related accidents



Page 9

However, the amount of damage that employee-related accidents caused was quite low relative to other types. When we asked enterprises to quantify the hard-dollar costs of the incidents they experienced, the most common incidents were also shown to be the least costly. The total cost for all lost smartphone incidents was $134,000, with about half incurring minimal or no costs. The average cost per incident was $12,000 (see Figure 6). Lost laptop incidents incurred slightly more cost and were slightly more serious, with a total cost of $179,000 and a per-incident cost of $26,000. Accidental leakages incurred just $174,000 in total cost and had a per-incident cost of $26,000.

Figure 6 . . . But Insider Theft Of Secrets And Other Unstructured Documents Was The Most Costly Type Of Incident

“Please quantify the total hard-dollar costs of the incidents over the last 2 years. Include any fines, legal fees, out-of-pocket investigation expenses, and forensics consulting. Do not include soft labor/productivity issues.”

Type of Incident Cost of incidents, last 2 years

Cost per incident

A rogue employee stole sensitive company documents (n=92) $380,701 $362,572

An outside business partner lost a laptop containing sensitive information (n=77)

$320,137 $340,571

An outside attacker compromised a server and stole data (n=68) $313,754 $295,994

An IT administrator abused privileges and stole data (n=73) $312,044 $452,238

An outside business partner lost sensitive information via other means (n=88) $303,268 $115,751

A supply chain or business partner abused their privileges and obtained data they should not have had access to (n=66)

$289,815 $362,269

IT operations lost an unencrypted backup tape or drive (n=84)

$277,481 $179,020

A terminated employee stole information because they had not been adequately de-provisioned (n=86) $265,759 $160,096

A rogue employee used their privileges to access sensitive company documents that they had no business reason to view/use (n=109)

$246,641 $82,214

A customer service representative inappropriately accessed customer records (n=87) $195,548 $54,929

An employee lost a laptop containing sensitive information (n=157) $179,341 $26,335

An employee accidentally emailed or posted sensitive information (n=152)

$174,242 $25,586

An employee lost a smartphone (n=159) $133,639 $11,826



By contrast, malicious theft by insiders and third parties was much costlier. Although enterprises reported, on average, only one incident where a rogue employee stole sensitive company documents, that one incident was the most costly of



Page 10

incident types: $380,000 in absolute terms, or roughly $363,000 per incident. Damage caused by a rogue IT administrator was even more costly on a per-incident basis, at $452,000. To put this in perspective, this means that employee theft of sensitive information is 10 times costlier on a per-incident basis than any single incident caused by employee accidents.

Conclusions: Enterprise security investments are overly biased toward preventing employee mistakes rather than securing the critical secrets that confer long-term competitive advantage. Many of the security controls that are believed to be “best practices” — full-disk encryption on laptops, data leak prevention (DLP) policies for detecting protected health information (PHI) or PII, and device control software — are designed to reduce the impact of employee accidents. Today, these controls are most commonly used to reduce the frequency of toxic data spills of custodial data. But they are used less often to prevent theft. Enterprises should focus more of their resources on stopping the most damaging incidents: deliberate theft by insiders and abuse by outsiders.

The More Valuable A Firm’s Information, The More Incidents It Will Have

For 90% of enterprises, collaboration tools that cross company lines are essential to the success of their businesses.5 The average enterprise in our survey works with more than 100 third parties. Nearly three-quarters of this total comes from links with contract professionals (30, on average), supply chain partners (29), and contract manufacturers (16). Regulatory agencies, CPAs, healthcare providers, and other organizations make up the rest.6

Forrester hypothesized that enterprises with the most valuable and widely shared information would incur far higher incident costs than others. To test this hypothesis, we divided the enterprises we surveyed into quartiles based on the value of their enterprise information portfolios. The top quartile based on enterprise information value, which we call the high-value quartile, manages information worth $4.8 million out of a maximum possible value of $5 million, of which $3.1 million is secrets and $1.6 million is toxic data (see Figure 7).7 The bottom quartile, called the low-value quartile, manages just $243,000 in information assets. In other words: High-value enterprises’ information is worth at least 20 times that of the low-value enterprises.

We noticed important differences in several key characteristics of high-value enterprises compared with the low-value enterprises. First, the number of connections with outside parties was much higher. High-value enterprises had 60% more relationships with outside third parties than low-value firms (168 parties versus 104). Second, high-value firms used more security controls than low-value firms. High-value firms have deployed approximately 16 process, endpoint, network, and data center controls to protect sensitive data, compared with 13.8 for low-value firms. Most of the difference is explained by technology (12.2 technical controls versus 10.2).8

Third, we noticed a striking difference in the number and kind of data security incidents that each group experienced. High-value firms reported four times as many data security incidents as low-value firms — about 60 (59.5) over a two-year period compared with about 15 (14.4). The roughly 4:1 proportion of incidents was true not just overall but with respect to incidents due to employees also. But with the difference in the number of outsider incidents, it was six times higher with high-value versus low-value firms. The more third-party connections an enterprise has, the more incidents it will have that come from outsiders.



Page 11

Figure 7 Firms With High-Value Information Portfolios Gain More, And Spend More, Than Low-Value Firms


Moreover, high-value firms incurred much higher incident costs than the low-value firms. A typical high-value firm’s cost of incidents, at $2.05 million over two years, was 50% more than the mean for all enterprises ($1.3 million). The high-value firms’ per-incident costs, at $35,000 per incident, are comparable with the mean for all companies ($33,000). High-value incidents are not necessarily more serious on a per-incident basis than those at other companies — but there are a lot more of them.

Conclusions: Enterprises with more valuable information portfolios must spend more time and effort securing them. Higher-value portfolios lead to more incidents. Our data shows that enterprises are not spending enough effort protecting data from theft and abuse by outside parties. High-value firms suffer six times more data security incidents due to outside parties than low-value firms, and the number of outside parties they work with is 60% greater. This shows that the combination of more valuable information and more widespread collaboration leads directly to higher security exposure.



Page 12

CISOs Do Not Know How Effective Their Security Controls Are

Enterprises implement a range of security controls to protect their sensitive data. Some of these are process controls, such as access controls on file shares, data classification procedures, or data breach reporting. Others are technical controls for the endpoint, network, or data center. Endpoint controls include full-disk encryption, device wipe software for mobile devices, and DLP. Network controls include DLP software for the network and email encryption software. Data center controls include DLP software, access control remediation, database monitoring, database encryption, and security information management (SIM).

When asked to rate the effectiveness of their security controls, respondents rated nearly every one highly. Sixty percent or more rated every single technical control we asked about as “highly effective.” A huge majority (95%) expressed high confidence that they know where their most sensitive information flows from and to.9

But enterprise confidence in the effectiveness of their controls is overstated. For example, both high-value and low-value firms rated their security programs equally effective — scoring 2.5 and 2.6, respectively, on a 3-point scale. But as we discussed in the previous section, the high-value firms had four times as many incidents as low-value firms. One of them must be wrong. We observed the same pattern when we compared the top and bottom quartiles for security spending and security incidents. In other words, no matter how we cut our data — by information asset value, spending, or number of incidents — the top and bottom quartiles all rated their program effectiveness between 2.5 and 2.6, even though the number and cost of incidents varied widely. We find this implausible.

Conclusion: Most enterprises do not actually know whether their data security programs work or not, other than by raw incident counting. Even then, an enterprise with a high number of incidents is still likely to imagine that its programs are “very effective.” To understand more objectively how well their security programs perform, enterprises will need better ways of generating key performance indicators and metrics — and we (Forrester) will need to ask more pointed questions to better understand the incidents they missed.

Conclusions And Recommendations

In analyzing the security practices of more than 300 North American, European, and Australian enterprises, Forrester Consulting confirmed several long-standing hypotheses about data security programs in large companies. We confirmed that, indeed, increased collaboration increases data security’s importance, and that compliance pressures continue to be the motor that turns the IT security budget wheel. We also confirmed the conventional wisdom that, 75% of the time, data security incidents are attributed to insiders.

However, we also reached some surprising conclusions. Forrester concluded that not all enterprises are created equally. High-value firms manage information that is 20 times more valuable than low-value firms. And they are much more eager collaborators. As a result, the number and type of data security incidents experienced by high-value firms were four times higher, and the costs are nearly twice as high.



Page 13

KEY RECOMMENDATIONS

CISOs invest significant time and money protecting their sensitive information. But their priorities are not always the right ones. Security investments are too often aimed at preventing accidents, such as when employees accidentally lose laptops or inadvertently send emails containing customer information. Enterprises are sensitive to these concerns because compliance with regulations, customer pressures, criminals, and contractual mandates make toxic data spills expensive.

“Compliance” in all its forms has helped CISOs buy more gear. But it has distracted IT security from its traditional focus: keeping company secrets secure. Forrester recommends that enterprises examine their current data security strategies to ensure that they are balanced and appropriate for the portfolios they are protecting. In the next 60 days, you should:

• Identify the most valuable information assets in your portfolio. As we have demonstrated in this report, some information assets are more valuable than others. Ask your organization’s asset owners to assign coarse-grained monetary values to their custodial data and secrets. Stack-rank the top five most valuable assets, and calculate the proportion that is “secrets” versus “custodial data.” Use the broad ratios in Figure 4 as a guideline to determine whether your enterprise contains more — or less — secrets than other enterprises in your vertical.

• Create a “risk register” of data security risks. Divide the risks your firm faces into two categories: compliance risks and misuse of secrets. For compliance, review the history of “toxic data spills” involving mobile devices and media. For misuse of secrets, review cases of abuse by users with access to valuable information. Examine the types of information given to third parties, especially the extent to which they are stored on non-company-owned assets. Create a risk register documenting the specific threat scenarios: what data is at risk and from whom, and the likeliest threat vectors the threat agents might exploit.

• Assess your program’s balance between compliance and protecting secrets. Your organization’s senior management has a set of principles that shapes what the security program does and the impulses it responds to. Requests to “protect our patients’ medical records” or “keep our company out of the papers” imply priorities for protecting custodial data. But “stop our designs from being stolen by our competitors” sends a different message. Understanding how your management’s priorities map to the security team’s control strategies is essential to understanding whether it is balanced.

These three actions will establish your security program’s baseline. Based on the results, you should then:

• Reprioritize enterprise security investments. Programs whose control strategies are “overweighted” toward compliance and preventing employee accidents should consider data-centric technologies like enterprise rights management (ERM), fine-grained access controls, and DLP. To increase acceptance by the employees who must protect the information, use a simple data classification strategy with just three levels: public, internal use only, and need-to-know. For reducing theft of secrets by privileged insiders, build core competencies in network security monitoring (NSM) and SIM.

• Increase vigilance of external and third-party business relationships. Enterprises with significant exposure to third parties should take steps to monitor and restrict information flows. If possible, mandate the installation of technical controls on third-party devices that store significant quantities of secrets or custodial data. Consider data-sharing strategies that don’t require third parties to store data on their devices, such as client virtualization.

• Measure effectiveness of your data security program. Security managers should rely on facts, rather than faith, for proof of effectiveness of their data security programs. Develop a process for tracking key performance indicators that measure the effectiveness of data protection efforts, such as frequency and cost of incidents. Wherever possible, benchmark against comparable firms using data from studies like this one or using public data sources like DataLossDB.



Page 14

Appendix A: Methodology

In this study, Forrester conducted an online survey of 305 organizations on three continents to evaluate data security drivers, practices, and costs. The survey base included 163 US-based companies, 102 in Europe, and 40 in Australia and New Zealand.

All companies we surveyed employed more than 5,000 people. Survey participants were decision-makers who had primary responsibility or authorization over IT security budgets. Questions provided to the participants asked basic demographic questions about their industry, number of employees, and IT and security budgets. Specific security question categories included:

• Business security drivers.

• Key perceived data security risks.

• Sensitive data types managed by the enterprises.

• Value of the top five most-important data types.

• In-use and planned data security controls.

• Data loss incidents, their sources, and their cost.

The survey totaled 30 high-level questions, many with multiple responses and multipart answers. In all, we obtained more than 2,000 data points per respondent.

The study began in November 2009 and was completed in December 2009.

Based on the results from the fielded survey, Forrester calculated the following key statistics for each company:

• Information value.

• Information value — toxic data.

• Information value — secrets.

• Number of outside parties.

• Number of security controls deployed.

• Mean effectiveness of security controls.

• Number of security incidents (past two years).

• Cost of security incidents.

We explain the calculation of each metric below.



Page 15

Information Value We assigned an information value to the top five types of information the respondents considered “important” or “very important.” We gave respondents several value ranges to choose from. For each data type, if the respondent said it was worth less than $50,000, we assumed that data type had no value. If the respondent said it was worth more than $1 million, we capped the value at $1 million. Otherwise, we used the midpoint of the range. We then took the sum of these values to calculate the overall value of the firm’s information. Put more correctly, this value should be seen as a lower-bound estimate of the value of the firm’s five most-important data types. Because we only asked respondents to assign values to five data types, the maximum value of a firm’s information is $5 million. We realize that many enterprises value their information higher than this.

The 17 data types that respondents could choose from were: plans for new products and services; sales pipelines and forecasts; customer contact information; earnings and financial information; PII about customers; cardholder data related to compliance with PCI; medical records and PHI; financial models; source code; clinical trial information; bills of materials; product schematics and CAD drawings; pricing lists; competitive analyses; proprietary research; mergers and acquisitions data; and other (please specify).

Information Value — Toxic Data We calculated the value of information that is “toxic” by virtue of regulation or a compliance mandate like PCI. To do this, we summed the information values as described in the previous paragraph, but only for these data types: customer contact information; PII about customers; cardholder data related to compliance with PCI; medical records and PHI; and clinical trial information.

Information Value — Secrets We calculated the value of “secrets” (trade secrets, confidential and other kinds of nonregulated but otherwise valuable data) by subtracting the “toxic data” value from the firm’s overall information value.

Number Of Outside Parties We asked respondents to tell us how many third-party firms their enterprises do business with. We asked for specific numbers for each of these types of third party: supply chain raw materials or finished goods suppliers; contract manufacturers; outsourced customer contact center/call centers; healthcare insurance providers; payroll processors; outsourced or contracted IT support firms; outsourced application development firms, including offshore; CPAs; management consultants with privileged access to company financials; regulatory agencies; and contract professionals used for seasonal work. The number of outside parties metric is the sum of all of these responses.

Number Of Security Controls Deployed We asked respondents to tell us how many process-related and technology-based security controls they used to secure their information. For each of 21 specific controls, we asked to what degree they were deployed within the respondent’s environment, ranging from not deployed to full deployment.



Page 16

We asked about five process controls: access controls; data security training; data incident/loss tracking; data breach reporting/response processes; and policies for classification and data protection.

We asked about six technical endpoint controls: device wipe/kill software for mobile devices; desktop/laptop port and device control software; file or folder encryption software; enterprise/information digital rights management; laptop or desktop full-disk encryption; and DLP software at the endpoint.

We asked about five technical network controls: DLP software for data in motion on the network; Web application firewall; email encryption software; email monitoring and filtering software; and encrypted file transfer software.

Lastly, we asked about five technical database and data center controls: database monitoring and protection tools; database encryption tools; DLP tools for discovering data at rest on servers/databases; security information and event management (SIEM) tools; and other.

The total number of security controls deployed is the count of the number of controls the respondent indicated they were “piloting” or have “fully deployed.”

Mean Effectiveness Of Security Controls For each security control that the respondent indicated was “fully rolled out,” we asked the respondent to grade its effectiveness on a 3-point scale, where 0 meant “shelfware,” 1 meant “not at all effective,” 2 meant “somewhat effective,” and 3 meant “very effective.” We then averaged the effectiveness score for all of the technologies to calculate a mean score for the enterprise.

Number Of Security Incidents (Past Two Years) We asked respondents to tell us the number of incidents they had experienced over the past two years for each of 14 specific kinds of incidents. One group of incidents was the type that an insider (employee) might commit; the other was for outsiders. Respondents could also indicate they experienced no incidents.

The “employee” incidents were nine different types: IT operations lost an unencrypted backup tape or drive; employee lost a laptop; employee lost a smartphone; IT administrator abused privileges and stole data; customer service representative inappropriately accessed customer records; employee accidentally emailed or posted sensitive information; rogue employee used his or her privileges to access sensitive company documents; rogue employee stole sensitive company documents; and terminated employee stole information because they had not been adequately deprovisioned.

The “outsider” incidents were five different types: outside business partner lost a laptop; outside business partner lost sensitive information via other means; outside attacker compromised a server and stole data; supply chain or business partner abused their privileges and obtained data they should not have had access to; and other.

The number of security incidents metric was the sum of the number of incidents for each type of incident. We further calculated metrics for the number of incidents by employees and the number of incidents by outsiders.



Page 17

Cost Of Security Incidents For each type of incident that the respondents indicated they had non-zero numbers of incidents for, we asked what the hard-dollar costs (excluding labor) were for all incidents of that type. For each type of incident, we gave the user several cost ranges to choose from, ranging from “minimal cost” (less than $1,000) to “large incident” (more than $1 million). If the respondent said the hard-dollar cost was less than $1,000, we assumed that the cost was zero. If the respondent said it cost more than $1 million, we capped the cost at $1 million. Otherwise, we used the midpoint of the range. To calculate the total cost of security incidents metric for a firm, we summed the costs for all incidents. We further calculated metrics for the average incident cost for each type of incident across all firms.

Appendix B: Supplemental Material

Related Forrester Research “Data Security Predictions For 2010” by Andrew Jaquith, December 2, 2009

“Selecting Data Protection Technologies” by Andrew Jaquith, October 28, 2009

“Inquiry Spotlight: Data Leak Prevention, Q1 2009” by Natalie Lambert and Andrew Jaquith, February 10, 2009

Appendix C: Endnotes

1 Source: David Drummond, “A new approach to China,” The Official Google Blog, January 12, 2010 (http://googleblog.blogspot.com/2010/01/new-approach-to-china.html). For Forrester’s take, see The Forrester Blog For Security & Risk Professionals. Source: Andrew Jaquith, “The Attack on Google: What It Means,” The Forrester Blog For Security & Risk Professionals, January 15, 2010 (http://blogs.forrester.com/srm/2010/01/the-aurora-attack-on-google-what-it-means.html).

2 For more about the major search engine company incident, see Forrester’s blog post. Source: Andrew Jaquith, “Plain speaking about industrial spying,” The Forrester Blog For Security & Risk Professionals, January 25, 2010 (http://blogs.forrester.com/srm/2010/01/plain-speaking-about-industrial-spies-not-apt.html).

3 Eighty-nine percent of respondents agreed (40%) or strongly agreed (49%) with this statement: “Compliance with incident disclosure laws, Payment Card Industry Data Security Standard (PCI-DSS), and data privacy regulations is the primary driver of our data security.” Source: “The Value Of Corporate Secrets,” a commissioned study conducted by Forrester Consulting on behalf of RSA and Microsoft, November 2009. Base: 305 senior-level IT security decision-makers. Question Q1: “Please indicate how strongly you agree or disagree with the following statements about your company’s use of communications technologies and their associated data security risks.”



Page 18

4 Forrester asked respondents to indicate the degree to which “the following regulations and compliance-related issues have driven your data security programs: a) statutes and regulations such as CA SB 1386, MA-201, Sarbanes-Oxley, ARRA, and the EU Privacy Directive; b) contractual standards like the Payment Card Industry Data Security Standard (PCI-DSS); c) ITAR/Export Control; and d) internal corporate IT security policy.” Source: “The Value Of Corporate Secrets,” a commissioned study conducted by Forrester Consulting on behalf of RSA and Microsoft, November 2009. Base: 305 senior-level IT security decision-makers.

5 Ninety percent of respondents agreed (46%) or strongly agreed (44%) with this statement: “Collaboration tools that cross company boundaries are essential to run our business.” Source: “The Value Of Corporate Secrets” a commissioned study conducted by Forrester Consulting on behalf of RSA and Microsoft, November 2009. Base: 305 senior-level IT security decision-makers. Question Q9: “Please indicate how strongly you agree or disagree with the following statements about your company’s use of communications technologies and their associated data security risks.”

6 Forrester asked each respondent to indicate how many third-party firms their enterprise does business with. We asked for specific numbers for each of 11 specific third-party categories. See Appendix A (Number of outside parties).

7 As described in Appendix A, an enterprise’s information portfolio value is calculated by summing the value assigned to each of the top five most-valuable information assets. Our survey conservatively capped the value of any type of information at $1 million.

8 See Appendix A for a description of “security controls” and how we measured deployment.

9 Ninety-six percent of respondents agreed (32%) or strongly agreed (64%) with this statement: “Data security is the most important security priority for our company.” Ninety-five percent agreed (44%) or strongly agreed (51%) with the statement, “We know where our most sensitive data flows to and from.” Source: “The Value Of Corporate Secrets,” a commissioned study conducted by Forrester Consulting on behalf of RSA and Microsoft, November 2009. Base: 305 senior-level IT security decision-makers. Question Q9: “Please indicate how strongly you agree or disagree with the following statements about your company’s use of communications technologies and their associated data security risks.”

memoria del proyecto

Technology