Seguridad y Riesgo

Manual de supervivencia de Seguridad de la Informacin
Episodio 1: Lo que todo iniciado debe conocer
Juan Ignacio Trentalance
Manual de supervivencia de Seguridad de la Informacin Episodio 1
Manual de supervivencia de Seguridad de la Informacin. Episodio 1: Lo que todo iniciado debe conocer. (c) Juan Ignacio Trentalance, 2010. Todos los derechos reservados. Cualquier comentario que el lector desee sobre este libro ser bienvenido a la siguiente direccin de correo electrnico: jtrental@gmail.com Se permite citar partes del libro, enviarlas por email a terceros, imprimirlas y publicarlas en blogs y otros medios, con la condicin de que no se modifique ni edite el texto, y se incluya el nombre del autor y la direccin de internet para descargar el material. El derecho de encuadernar este material y venderlo en forma de libro est estrictamente reservado. Este libro es una obra en progreso y el presente documento data del 21 de enero de 2010. La ltima versin se puede descargar en: http://www.portoyasociados.com.ar/manual_seginf_episodio1.pdf
(c) Juan Ignacio Trentalance, 2010.
Agradezco especialmente a Karina Macci y a Marcelo Mastromarino, quienes soportaron la lectura de esta obra y me hicieron una detallada devolucin con sus mejoras y aportes.
ndice
1 Por qu este libro .......................................................................................... 5 2 La gestin de la Seguridad de la Informacin ............................................... 8 2.1 Por qu protegemos la informacin: datos, informacin y sistemas ..... 9 2.2 Qu significa proteger la informacin.................................................. 10 2.3 Las buenas prcticas en Seguridad de la Informacin ....................... 11 2.4 Alta Direccin y Poltica Corporativa de Seguridad............................. 14 2.5 Activos a proteger ............................................................................... 15 2.6 Clasificacin de la Informacin ........................................................... 17 2.7 Gestin de Riesgos ............................................................................. 18 2.7.1 Anlisis de Riesgos .................................................................. 20 2.7.2 Anlisis de Riesgos Cuantitativo .............................................. 21 2.7.3 Anlisis de Riesgos Cualitativo ................................................ 23 2.7.4 Evaluacin de Riesgos ............................................................. 25 2.7.5 Tratamiento de Riesgos ........................................................... 28 2.8 Controles y Contramedidas................................................................. 31 2.9 Roles y Responsabilidades ................................................................. 32 2.10 Documentacin ................................................................................... 34 2.11 Gestin de Incidentes ......................................................................... 37 2.12 Gestin de la Continuidad del Negocio ............................................... 38 2.13 Cumplimiento (Compliance) ................................................................ 40 2.14 Otros aspectos: tecnologa, personas y seguridad fsica .................... 42 A Anexos ........................................................................................................ 44 A.1 Bibliografa utilizada ............................................................................ 44 A.2 Acerca del Autor ................................................................................. 45
1 Por qu este libro
Figura 1.1. La mam de Dilbert1. A principios de la dcada del 70, los pases centrales iniciaron una transformacin donde dejaron paulatinamente de ser sociedades industriales para convertirse en sociedades de la informacin o del conocimiento2. La generacin de la riqueza dej de estar tan vinculada a la produccin de bienes tangibles para dar paso, cada vez ms, a la prestacin de distintos tipos de servicios: diseo, entretenimiento, educacin, provisin de un producto, transporte, etc. El servicio de delivery, o entrega de un producto, es ms trascendente que su propia produccin. Esta transformacin fue posibilitada por el explosivo avance, difusin y abaratamiento de la tecnologa informtica subyacente (el hardware, el software, las redes de comunicacin, etc.), hasta tal punto que la generacin, almacenamiento y transmisin de la informacin, se ha vuelto un aspecto fundamental en la economa de la mayora de las naciones. La informacin ha cobrado un rol preponderante para nuestra vida en general (y para las organizaciones en particular), cuidarla es una tarea que se vuelve cada vez ms relevante (ver figura 1.1). Durante largo tiempo no entenda a qu se referan en las pelculas cuando un oficinista le deca a otro leste el ltimo memo?. En la oficina donde trabaj, usbamos el telfono para comunicarnos y en todo caso envibamos un correo electrnico (corporativo) para dejar
Dilbert es un personaje de Scott Adams (tambin autor del libro The Dilbert Principle) que trabaja como ingeniero en una corporacin que se dedica a la venta de productos y servicios de tecnologa. Las tiras cmicas de Dilbert expresan de una manera muy inteligente la problemtica humana que encontramos en las organizaciones. La fuente de esta tira cmica es http://www.dilbert.com, la fecha de publicacin es 12 de abril de 2006: - Su software de seguridad est desactualizado... - Oh oh. - Deseara pasar el resto de su vida natural tratando de entender cmo actualizarlo?... - ... o preferira dejar que los hackers le roben la identidad, vacen su cuenta bancaria, y destruyan su disco rgido? - Necesito ms opciones! 2 La sociedad de la informacin es un trmino popularizado por el autor Fritz Machlup, en su trabajo La produccin y distribucin del conocimiento en los Estados Unidos de 1962. Los trminos sociedad de la informacin y sociedad del conocimiento no significan exactamente lo mismo, pero su discusin excede el objetivo del libro.
1
algo por escrito. Aos despus descubr que el memo era una hoja impresa, a veces con un header con destinatario, remitente y asunto (como si fuese un mail, deca yo), utilizada para las comunicaciones oficiales. Hoy en da es difcil concebir un trabajo de oficina sin el uso de una extensin telefnica personal, una computadora con correo electrnico corporativo, la posibilidad de compartir documentos en formato digital y el acceso a Internet. En este libro se trata el proceso de implementacin de las buenas prcticas de Seguridad de la Informacin en una organizacin. Su contenido est inspirado en la recopilacin de una serie de conferencias que present en diversos ambientes a lo largo de los ltimos 6 aos3. El recorrido de los temas sigue mi propia evolucin como profesional de la Seguridad de la Informacin. Me inici en el campo de la seguridad en abril del 2000, cuando era todava una novedad, en una empresa de servicios tecnolgicos con una estructura de organizacin innovadora4. Como Analistas de Seguridad Informtica nuestra tarea era doble: por un lado estaba el anlisis sobre las condiciones de seguridad, y por el otro la administracin de la tecnologa de seguridad de la empresa. Todo lo que hacamos se centraba en la tecnologa: desde la administracin de perfiles de usuarios (o reseteo de passwords, las tareas tradicionales de Seguridad Informtica), hasta la administracin de los firewalls de las redes de la organizacin (incluyendo la red de servicios corporativos y otras redes que brindaban servicios directamente al cliente). Pensbamos que controlando la tecnologa mantenamos la Seguridad de la Informacin de la empresa. A lo largo de mi carrera me dediqu a administrar equipos de seguridad, adoctrinar y capacitar a administradores de sistemas sobre seguridad, realizar revisiones en equipamiento, participar de definiciones en proyectos de tecnologa (nuevos y existentes), analizar informacin de seguridad (y desarrollar herramientas ad hoc para poder manejar el volumen), investigar y desarrollar tecnologa de seguridad, liderar un grupo de seguridad operativa (junto con los usuarios, los administradores, nuestro jefe, nuestro director, los otros directores, etc. que vienen asociados), vender software y hardware de seguridad (convenciendo a los clientes de que la solucin a sus problemas era la tecnologa), implementar los productos y dar soporte a los clientes (pre y pos venta), y por ltimo, asesorar a las organizaciones en la implementacin de las buenas prcticas de Seguridad de la Informacin (incluyendo establecimiento de planes de continuidad del negocio, implementacin de sistemas de gestin, gobierno corporativo, e incorporacin de tecnologa de seguridad).
Entre otros, en eventos organizados por ISSAArBA (Information Systems Security Association, captulo de Buenos Aires, Argentina) junto con Microsoft, Universidad de Buenos Aires (UBA), Universidad Tecnolgica Nacional y el captulo argentino de AFCEA (Armed Forces Communications and Electronics Association); en eventos de la industria como Infosecurity y Segurinfo; y como docente de posgrado de la Especializacin en Servicios y Redes de Telecomunicaciones de la Facultad de Ingeniera de la UBA. 4 Ver Mintzberg, Henry: Mintzberg y la Direccin, Madrid, Ediciones Daz de Santos, 1991. La estructura de este tipo de organizaciones suele modificarse con frecuencia para hacer frente a un contexto por lo general dinmico. En este caso, se trataba de una industria joven de servicios tecnolgicos como lo era la comunicacin celular hace unos aos.
3
Casi diez aos ms tarde, tanto las buenas prcticas de la seguridad como yo hemos evolucionado considerablemente, de un enfoque exclusivo en los aspectos tecnolgicos, a uno basado en la gestin de la organizacin y su negocio. O tal vez deba decir que las buenas prcticas ya haban evolucionado en el 2000, cuando Bruce Schneier llegaba a la conclusin de que la seguridad es un proceso, no un producto5, pero que recin ahora se empiezan a dar las condiciones como para ponerlas en prctica. Siguiendo el mismo eje temtico, esta obra se estructura en tres episodios: 1. Episodio 1: cules son las actividades, recursos y tcnicas que debemos gestionar segn las buenas prcticas. 2. Episodio 2: cules son los desafos a la hora de pasar de la teora a la prctica, cules son los cuellos de botella y los problemas con los que nos encontramos. 3. Episodio 3: cmo superar en la prctica los desafos planteados mediante la implementacin de un Sistema de Gestin de Seguridad de la Informacin6.
Schneier, Bruce: Secrets and Lies: Digital Security in a Networked World, Nueva York, John Wiley & Sons, 2000. 6 En el contexto de este libro, el trmino Sistema de Gestin no se utiliza para denotar un Sistema Informtico (en el sentido de un software que corre sobre un determinado hardware), sino todos aquellos elementos (personas, procedimientos, polticas, tecnologa, etc.) utilizados para dirigir o gobernar una organizacin.
2 La gestin de la Seguridad de la Informacin
Figura 2.1. Mordac, el impedidor de Servicios Informticos.7 Hace unos aos se deca que los profesionales en el rea de Seguridad Informtica debamos preocuparnos slo por la seguridad, y que de la funcionalidad se preocuparan los usuarios, como se muestra en la figura 2.1. Desde el punto de vista de lo actitudinal, ramos profundamente paranoicos y restrictivos para con los malditos usuarios. Para nosotros, la seguridad era lo contrario de la funcionalidad, y nuestra misin consista en buscar los medios para impedir que la tecnologa fuese usada de manera insegura en la organizacin. Si lo que describo le suena al lector exagerado, piense por un momento en lo siguiente: al finalizar la auditora de seguridad que realiz la desaparecida Arthur Andersen sobre el sector de Seguridad Informtica donde yo trabajaba en noviembre de 2000, nos felicitaron por estar alineados con las best practices de la industria. Si sigue pareciendo una exageracin, medite en lo reciente que es la fecha de publicacin de la caricatura de la figura 2.1. Nunca nos habamos puesto a analizar en detalle cul era la informacin que debamos proteger, ni cul era su importancia para el negocio, ni por qu era tan importante protegerla. Tratbamos de proteger toda la informacin que encontrbamos, con la misma intensidad y esfuerzo. Este enfoque se ha demostrado poco til por varios motivos. Para empezar, es ineficiente, porque al proteger la informacin por la informacin misma se gastan los recursos de manera arbitraria, llegndose a casos en los que lo que se protege vale mucho menos que lo que cuesta protegerlo. Es ineficaz, porque si no entendemos cul es la funcin que cumplimos para el negocio de nuestra organizacin, corremos el riesgo de olvidarnos de las amenazas ms importantes. Para ejemplificar este punto podramos usar varias analogas, como la de Francia al comienzo de la Segunda Guerra Mundial, que se olvid de protegerse de un posible avance alemn a travs de Blgica, pero es un poco trillado. Prefiero un ejemplo de mi experiencia profesional: protegamos con mucho celo la seguridad de la red mediante reglas del
7
http://www.dilbert.com, 16 de noviembre de 2007: - La seguridad es ms importante que la usabilidad. - En un mundo perfecto, nadie debera ser capaz de usar nada. - Para completar el procedimiento de ingreso al sistema, mire fijamente al sol.
firewall, pero nos olvidbamos de involucrarnos en el proceso de desarrollo y adquisicin de los sistemas comerciales (ERP, CRM, etc.) que usaba la organizacin, donde se almacenaba buena parte de la informacin del negocio. En el largo plazo genera una suerte de resistencia biolgica en los usuarios, que se convierten en hackers por necesidad, porque las trabas impuestas para que puedan desarrollar sus actividades son tan grandes (a ellos se les paga por usar la informacin, no por protegerla) que terminan encontrando los medios para, o bien bypassear los controles, o directamente evitar a toda costa que la gente de seguridad participe de los proyectos. Esto vuelve imposible la toma de conciencia de los usuarios, porque cmo van a apoyar una iniciativa que les impide llevar a cabo el negocio de la organizacin? En este captulo cubriremos los aspectos estratgicos de la gestin de la Seguridad de la Informacin. La estrategia se fija de acuerdo con una serie de directrices o ideas fuerza hacia las que se quiere avanzar, tales como gestionar los riesgos del negocio, aprender de los incidentes, identificar controles tcnicos, administrativos y fsicos, entre otras. Sin embargo, una condicin previa es la importancia de alinear el esfuerzo con los objetivos del negocio. Sin esta alineacin, la estrategia del negocio va a carecer de una real contribucin del rea de seguridad, producindose un malgasto de recursos asignados, o directamente la no asignacin por su falta de importancia. Muchas de las directrices que una organizacin debe considerar para su estrategia de Seguridad de la Informacin son recopiladas en las llamadas buenas prcticas (o la teora), que sern el principal foco del captulo 2.
2.1 Por qu protegemos la informacin: datos, informacin y sistemas

Volvamos brevemente a la figura 1.1 del captulo 1 y preguntmonos por qu, (o para qu) necesitamos proteger la informacin. La madre de Dilbert se enoja porque no tiene suficientes conocimientos para tomar una decisin (proteger su vida personal) y necesita ms opciones. El sistema le ofrece una cantidad de datos que ella es incapaz de manejar. Tal vez le est faltando que el sistema le provea menos datos y ms informacin. Para contestar la pregunta, debemos considerar las siguientes definiciones:8 Dato: es una forma abstracta de representar un aspecto de la realidad, por ejemplo, una cantidad de algo. Informacin: son los datos previamente seleccionados, o procesados de alguna manera que ayudan a alguien en la toma de decisiones.
Un dato puede o no ser informacin, en funcin de quin lo utiliza. La misma informacin que a un especialista en computacin le permite actualizar su antivirus y proteger su computadora, para la madre de Dilbert son solamente
8
Estas definiciones estn tomadas de Saroka, Ral Horacio: Sistemas de la Informacin en la Era Digital, Buenos Aires, Fundacin OSDE, 2002.
datos abstractos e inentendibles. De igual manera, muchos datos no necesariamente equivalen a mucha informacin. Para ilustrar esto de una manera muy sencilla, tomemos la definicin que da la norma ISO 9001: Informacin: datos que poseen significado9. Los datos son convertidos en informacin, y la informacin es adquirida, procesada, almacenada, transmitida, y presentada por sistemas (informticos, de comunicaciones, lingsticos, etc.). Existe toda una Teora de Sistemas de principios del siglo XX10. Un sistema es una entidad compuesta por un conjunto de partes interrelacionadas que, por lo general, tiene un objetivo; toma una entrada, realiza un proceso y se obtiene una salida; tiene demarcado un lmite (afuera y adentro del sistema); su comportamiento es difcil de explicar considerando sus componentes por separado; y puede estar contener subsistemas o ser parte de un sistema ms grande en una jerarqua de sistemas (por ejemplo, un planeta y sus lunas es un sistema dentro del sistema solar). Los sistemas pueden usarse para explicar muchos conceptos: sistemas de informacin (cuando las entradas y salidas del sistema son informacin), sistemas de comunicaciones, sistemas solares, un proceso de negocios, una organizacin, la sociedad (por ejemplo, el sistema capitalista). Tal vez la revolucin producida por el abaratamiento de la electrnica (ya mencionado en el captulo 1) hace que muchas veces se piense en un software corriendo sobre un hardware al referirnos a un sistema informtico. Sin embargo, en lo que resta del captulo, vamos a utilizar el significado ms amplio posible (en especial ms adelante, cuando hablemos de sistemas de gestin). La informacin es importante en la organizacin porque nos permite tomar decisiones informadas -valga la redundancia- y en consecuencia, el flujo de intercambio entre los distintos componentes de la organizacin (el sistema) es vital para la realizacin de su negocio. Hablamos de cualquier tipo de organizacin, no slo las comerciales, por lo que debe entenderse por negocio a su actividad, misin, o razn de ser. Con frecuencia se cita la siguiente frase para ilustrar esta relacin: la informacin es a la organizacin lo que la sangre al organismo humano.
2.2 Qu significa proteger la informacin

Cuando hablamos de Seguridad de la Informacin, nos referimos a la preservacin de tres propiedades fundamentales, a saber:
ISO 9000:2005 - Sistemas de Gestin de la Calidad - Fundamentos y Vocabulario, Suiza, ISO, 2005 (traduccin certificada), seccin 3.7. La familia de normas ISO 9000 (ISO 9000, ISO 9001 e ISO 9004) son una compilacin internacional de buenas prcticas de gestin de la calidad, ampliamente utilizadas, validadas y actualizadas a lo largo de varias dcadas, en varias organizaciones a lo largo del mundo. Los estndares ISO se tratan con ms detalle en el episodio III. 10 Saroka, ibid.
10
Confidencialidad: la informacin solamente es accedida con la debida autorizacin, y que nadie (ni nada) tome conocimiento de informacin que no debe conocer. La proteccin de esta propiedad es la principal funcin (aunque no la nica) de la criptografa. Integridad: que la informacin a la que se est accediendo no haya sido modificada en forma accidental o intencional en forma no autorizada. Disponibilidad: que la informacin est accesible para el uso autorizado de la forma apropiada y en el momento en que sea necesario.
Por otro lado, podemos referirnos a estas tres propiedades en funcin de sus principales amenazas, a saber: Divulgacin: cuando se produce una prdida o falta de confidencialidad en la informacin. Por ejemplo, cuando se hacen pblicos los planos del prototipo de un producto nuevo que est por salir al mercado. Alteracin: cuando se produce una prdida o falta de integridad en la informacin. Por ejemplo, los datos de un balance comercial deben ser apropiadamente protegidos de alteraciones para presentar a los accionistas el estado financiero de la empresa en forma confiable (recordemos el escndalo Enron). Destruccin (o Denegacin de Servicio): cuando se produce una prdida o falta de disponibilidad en la informacin. Una denegacin de servicio puede impedir que se acceda a determinada informacin, a pesar de que su confidencialidad o integridad dentro del sistema no se hayan afectado.
Existen otras propiedades adicionales que nos interesa preservar en la informacin, como por ejemplo, la Autenticidad (que la fuente de la informacin sea identificada en forma confiable), el No Repudio (que existan mecanismos que impidan a la fuente decir posteriormente que no gener esa informacin), y el Registro de la Responsabilidad (o Accountability, que se puedan consultar las personas o entidades que modificaron, o accedieron a la informacin, junto con da, hora, etc.), entre otras. En general, no son propiedades de la informacin en s, sino de las entidades que la generan, transmiten o manipulan, y que indirectamente preservan las tres propiedades fundamentales.
2.3 Las buenas prcticas en Seguridad de la Informacin

En la seccin anterior se establecieron los objetivos de la Seguridad de la Informacin (las propiedades que debemos preservar y las amenazas que debemos prevenir). Pero desde el punto de vista de la gestin, se presentan grandes desafos para mantener el esfuerzo a lo largo del tiempo. Para tal fin, distintos sectores de la sociedad han empezado a recopilar una serie de buenas prcticas, bastante alineadas entre s. A saber: Normas ISO/IEC 27001:2005 y 27002:2005: son los requisitos para la implementacin de un Sistema de Gestin de Seguridad de la Informacin (similar al Sistema de Gestin de la Calidad basado en ISO 9001) y el
(c) Juan Ignacio Trentalance, 2010. 11
cdigo de buenas prcticas de Seguridad de la Informacin, respectivamente. Common Body of Knowledge (CBK) del International Information Systems Security Certification Consortium o (ISC)2: es el cuerpo de conocimiento mantenido desde hace varios aos por (ISC)2 como las buenas prcticas que un profesional de Seguridad de la Informacin debe manejar11. COBIT (Control Objectives for Information and Related Technology) del Information Technology Governance Institute (ITGI): son las buenas prcticas relacionadas con la tecnologa de la informacin desde el punto de vista de la gobernabilidad y el control interno. National Institute of Standards and Technology (NIST) - Information Technology Security and Networking (ITSN) Division: es un organismo gubernamental de Estados Unidos que provee buenas prcticas de Seguridad Informtica, relacionadas con la tecnologa y las redes de comunicaciones, pero que no son ajenas a la evolucin hacia el enfoque integral del que venimos hablando.
Si bien existen muchas escuelas y orgenes para las buenas prcticas, poco a poco, la industria de la Seguridad de la Informacin en su conjunto ha empezado a entender que lo importante para mantener en el tiempo el esfuerzo de proteccin es cmo gestionamos una amplia variedad de elementos (procesos, personas y tecnologa) para proteger los activos12 de informacin de las amenazas (ver esquema de la figura 2.2). Todas las buenas prcticas coinciden en lo siguiente: Se alnea la Seguridad de la Informacin con el negocio, y se reconoce que es una funcin estratgica del negocio, pero no un fin en s mismo. Se agrega el apoyo de la Alta Direccin como factor clave de xito. Se gestionan procesos, personas y tecnologa. Se identifica qu informacin proteger, de qu amenazas y cmo hacerlo con una metodologa de gestin de riesgos. Se habla el mismo lenguaje que el Director de Finanzas, y cuando es posible, hasta se calcula el retorno de las inversiones en Seguridad de la Informacin. Se separa la funcin de Seguridad de la Informacin de las reas de Tecnologa o Sistemas y se la coloca como rea de staff para que exista un control por oposicin de intereses (seguridad versus funcionalidad). Se implementa un programa de entrenamiento y toma de conciencia en seguridad para usuarios, administradores, y otros involucrados. Se ampla el alcance de la Seguridad de la Informacin para abordar otros temas como Seguridad Fsica, Continuidad del Negocio, Recursos Humanos y Cumplimiento.
11
Este consorcio es el que Certifica a los Profesionales de Seguridad de la Informacin (CISSP, Certified Information Systems Security Professional). 12 Los activos de informacin se vern con ms detalle en la seccin 2.5.
12
Tecnologa
Activos Procesos Personas
Amenazas
Figura 2.2. Cmo gestionamos la Seguridad de la Informacin. El cambio cultural en los ltimos aos ha sido tan profundo en lo referido a las buenas prcticas, que en espaol hemos aceptado de buena gana reemplazar en nuestro vocabulario el trmino Seguridad Informtica por Seguridad de la Informacin. De esta manera se enfatiza la idea de que debemos proteger la informacin en cualquier medio en el que se encuentra, no solamente en los informticos. Para ilustrar lo anterior, vanse los ttulos en los que se organizan los controles de seguridad en la norma ISO/IEC 27001: A 5. Poltica de seguridad (Security policy) A 6. Organizacin de la Seguridad de la Informacin (Organization of Information Security) A 7. Gestin de Activos (Asset Management) A 8. Seguridad de recursos humanos (Human resources security) A 9. Seguridad fsica y ambiental (Physical and environmental security) A 10. Gestin de las comunicaciones y operaciones (Communications and operations management) A 11. Control de accesos (Access control) A 12. Adquisicin, desarrollo y mantenimiento de sistemas de informacin (Information systems acquisition, development and maintenance) A 13. Gestin de incidentes de seguridad de la informacin (Information security incident management) A 14. Gestin de la continuidad del negocio (Business continuity management) A 15. Cumplimiento (Compliance) De la Seguridad Informtica tradicional se encargan los controles en A.10 y A.11 de la norma ISO 27001. Se han agregado una serie de controles para gestionar correctamente el inventario de activos de informacin (A.7), la seguridad del personal (A.8), la seguridad fsica (A.9), la adquisicin y desarrollo de los sistemas (A.12), los incidentes (A.13), y preservar la continuidad del negocio (A.14). Pero tambin se han considerado los aspectos organizacionales, como establecer una poltica corporativa (A.5), y organizar
13
las responsabilidades de la seguridad (A.6). De todas las recomendaciones y buenas prcticas sugeridas, las fundamentales (en el sentido en que deben ser las precedentes a todo esfuerzo en materia de Seguridad de la Informacin) son las nociones de Responsabilidad de la Direccin y Poltica de Seguridad que se exponen en la prxima seccin.
2.4 Alta Direccin y Poltica Corporativa de Seguridad

La experiencia demuestra que la Seguridad de la Informacin no existe fuera del negocio de una organizacin. Sin ste, la seguridad carece de propsito. La seguridad sirve al negocio, y tiene sentido en la medida en que sta proteja la informacin relacionada con el negocio. Esta visin, cada vez ms aceptada por las buenas prcticas, es en realidad una obviedad para la Alta Direccin, y se aplica desde hace muchos aos a todas las funciones de una organizacin, en especial, en aquellas actividades consideradas de soporte. La pregunta implcita en la mente de todo gerente general a la hora de invertir recursos es Cmo va a mejorar esto nuestro negocio?. Alta Direccin o simplemente Direccin, es un trmino muy utilizado para referirse a los altos niveles jerrquicos de una organizacin, ya sea el dueo, el CEO, el presidente, el directorio, los gerentes, etc. En cualquiera de sus facetas, la Alta Direccin tiene un eje comn: la necesidad de tomar rpidamente decisiones trascendentes para mejorar el negocio. Casi siempre involucran algn tipo de inversin, ya sea en dinero, en tiempo, o simplemente asignando prioridades (qu tareas relegar cuando los recursos son escasos). Es por este motivo que sin el apoyo de la Alta Direccin, no es posible mantener a lo largo del tiempo -ni siquiera empezar, en verdad- el esfuerzo de seguridad. La Seguridad de la Informacin no debe convertirse en un proyecto que una oscura rea tcnica dentro de una gerencia debe vender internamente en los niveles altos de la organizacin, sino un concepto que la Alta Direccin entiende, acepta y baja por el organigrama a las dems reas. Tampoco puede ser un proyecto asignado a un rea, sin la provisin de recursos adecuados, ni la alineacin de los dems sectores de la organizacin. La Alta Direccin tiene, sin embargo, ciertas responsabilidades que cumplir. Despus de todo, frente a un incidente de seguridad, es sta quien debe dar explicaciones a sus accionistas, clientes, pblico, y dems partes interesadas (o stakeholders). Debe establecer efectivamente la intencin de implementar un programa de seguridad para que la organizacin en su conjunto sepa hacia dnde se dirige, y cules son los objetivos perseguidos. En primer lugar, debe publicar y establecer una Poltica Corporativa de Seguridad. Se trata de una expresin de deseo de muy alto nivel que establece las directrices que se van a seguir en el esfuerzo de seguridad. Es concisa, resumida, y tpicamente dice el qu, pero no el cmo. Es un documento que, si bien debe mantenerse actualizado y aplicable al negocio, no cambia con frecuencia.
14
Luego debe disear adecuadamente la estructura organizacional para que las responsabilidades de Seguridad de la Informacin puedan cumplirse realmente, por ejemplo, estableciendo un rea de staff de seguridad, para mantener el principio de control por oposicin de intereses (como ya dije, funcionalidad versus seguridad). El concepto de control por oposicin de intereses no siempre es bien entendido por los administradores de seguridad. Muchas veces se traduce en una necesidad de pelearse con las reas controladas y convertirse en una mquina de impedir. Es una actitud intil, ya que a la larga va a prevalecer la necesidad de funcionalidad por sobre la seguridad que requiere el negocio, y la Alta Direccin. En definitiva, debe ser una caracterstica del diseo de la estructura organizacional, ms que una motivacin de un rea funcional. Las responsabilidades de la Alta Direccin no terminan aqu. Debe evitarse que la Poltica se convierta en letra muerta, para lo que se requiere que las personas de la organizacin no solamente lean, sino que entiendan en qu medida sus funciones aportan al cumplimiento de los objetivos de seguridad (y en definitiva, a la Poltica). Asimismo, la Alta Direccin debe proveer los recursos suficientes para desplegar los lineamientos de la Poltica. Por ejemplo, invirtiendo dinero para adquirir tecnologa, modificar procesos, y entrenar a las personas, pero tambin asignando responsabilidades y priorizando adecuadamente las tareas. Es en este punto donde se espera del responsable del rea Seguridad de la Informacin que sea lo suficientemente inteligente como para justificar, en trminos del negocio, los recursos requeridos. Si un oficial de seguridad empieza a hablar en trminos absolutos o tratando de generar miedo, incertidumbre y duda (o FUD, por fear, uncertainty and doubt) puede pasar que se malgasten los recursos en actividades que no aportan al negocio, y/o que no se le asignen los recursos necesarios para protegerlo adecuadamente. Hasta aqu hemos sentado las bases para gestionar exitosamente un programa de seguridad. En ese sentido, constituye el primer hito, sin el cual carece de propsito seguir avanzando en tcnicas y recomendaciones de seguridad. En el resto del captulo se desarrolla, con cierto detalle, el contenido de las buenas prcticas, qu implicancias tienen stas sobre las organizaciones, y qu elementos debemos gestionar (con la conclusin implcita de que no son pocos) para dar una idea de la magnitud del esfuerzo requerido. Para quienes tengan nociones sobre Seguridad de la Informacin, es recomendable revisar rpidamente los ttulos de las secciones que siguen y continuar la lectura directamente en la seccin 2.14.
2.5 Activos a proteger

Normalmente, cuando pregunto en una organizacin cul es la informacin que es importante para el negocio que se proteja? suelo obtener respuestas como las siguientes: yo quiero que la gente no baje programas con virus de Internet, me gustara contar con una sala donde se pueda hablar sin miedo a
15
que haya micrfonos o directamente me responden con otra pregunta: te ests refiriendo a que tenemos que encriptar los mails?. En muchos de los casos, la forma natural de abordar la Seguridad de la Informacin es pensando en amenazas que no queremos que ocurran, o directamente en controles que deberamos aplicar. Sin embargo, el primer paso debera ser abstraerse de las posibles amenazas y concentrarse en la relacin que existe entre el negocio de la organizacin y su informacin. Un activo de informacin es, justamente, algo que surge de esa relacin. Aqu se presenta un listado de los distintos tipos de activos que deben considerarse: Informacin: en cualquier medio, como bases de datos y archivos con datos, contratos y acuerdos, documentacin impresa o en lnea, informacin de investigacin, manuales y material de entrenamiento, procedimientos, pistas de Auditora. Software: de aplicacin, de base, herramientas y utilitarios de desarrollo. Activos Fsicos: equipos de computacin, equipos de comunicaciones, medios de almacenamiento, centros de cableados. Servicios: de computacin y comunicaciones, de soporte (electricidad, aire acondicionado, iluminacin, calefaccin). Procesos: pueden incluir a las actividades crticas del negocio, procesos estratgicos, o de soporte. Personas: junto con su experiencia, conocimiento, capacidades y competencias. Activos Intangibles: pueden incluir la reputacin e imagen de la organizacin, o el valor (para los accionistas o el mercado) de su marca.
La informacin debe cuidarse a lo largo de su paso por los ms variados medios: en el mainframe donde est almacenada, en el cable cuando es transmitida a la impresora, en la hoja impresa de la bandeja, en la propia mente de quien la ley, y en el cesto de basura donde esa hoja fue descartada. Pero el listado de activos no se agota en los relacionados slo con la informacin, sino tambin con el propio negocio de la organizacin, como es el caso de los activos intangibles o los procesos del negocio. Por ejemplo, la funcin principal de un Plan de Contingencias es asegurar la continuidad de los procesos del negocio, frente a una serie de amenazas disruptivas. Las buenas prcticas definen algunos atributos importantes de los activos para establecer prioridades a la hora de protegerlos. Los tres atributos ms destacados son: Dueo: es el responsable por el activo y las decisiones relacionadas con ste. No debe entenderse con el sentido de quien ejerce derechos de propiedad sobre el activo, ya que esto lo hace la propia organizacin (o los accionistas, socios, etc). Por ejemplo, es normal considerar al Gerente de Marketing como dueo de la base de clientes, pero esto no significa que pueda venderla a terceros (de hecho, sera causal de despido).
16
Custodio: es el responsable de implementar la proteccin delegada por el dueo. Comnmente, es una tarea que se delega a reas de tecnologa o de seguridad. Clasificacin: es el grado de importancia definido por el dueo en funcin a diversos criterios, por ejemplo, qu tan confidencial, ntegra o disponible debe permanecer la informacin.
A partir de estos conceptos se escinden las decisiones sobre por qu proteger los activos de cmo hacerlo. El dueo define el por qu, ya que conoce claramente cul es la informacin importante para el negocio. El cmo queda a criterio del custodio, quien entiende mejor qu tecnologa, o procesos administrativos dan mejores resultados. Esta separacin de responsabilidades produce una negociacin entre dueos y custodios que mejora la relacin costo-beneficio de la proteccin de los activos. El dueo, muchas veces el propio generador y/o usuario, pretende que el activo sea protegido por todos los medios posibles. Nadie conoce mejor que el dueo la real importancia de la informacin para el negocio. Por su parte, el custodio va a cuidar la carga operativa y el presupuesto asignado. Aqu se da un verdadero control por oposicin de intereses, ya que el dueo va a exigir los controles adecuados para proteger sus activos, y el custodio, por su parte, que el dueo sea realista a la hora de definir prioridades. Una tpica frase del custodio al dueo bien puede ser: No vale que todos tus activos sean altamente crticos. Durante una consultora, el dueo de una base de datos sostena que la disponibilidad era un atributo crtico del activo, pero el custodio, al escucharlo, le contest: Eso no es as, el mes pasado se cay la base de datos durante tres das y fui yo quien se los comunic, ustedes ni se haban enterado.
2.6 Clasificacin de la Informacin

La clasificacin de la informacin es una actividad muy importante porque no toda la informacin tiene el mismo valor, ni est expuesta a las mismas amenazas, ni merece el mismo grado de proteccin. La clasificacin de los activos permite una mejor focalizacin de los controles en aquellas reas que ms los requieren. Estos activos son clasificados de acuerdo con su valor para la organizacin, directamente proporcional al impacto frente a una prdida de confidencialidad, disponibilidad o integridad de la informacin relacionada. Clasificarlos puede ser tan sencillo como definir si la informacin es confidencial, de uso interno, sensible, o de acceso pblico. Lo difcil es mantener un inventario unificado y consistente en toda la organizacin, y con procedimientos para que todo el personal entienda los cuidados que se deben adoptar. Es decir, la gestin del inventario, y su posterior clasificacin, etiquetado y manipulacin. Tradicionalmente, la clasificacin se asociaba a los ambientes militares, donde les preocupaba la confidencialidad de la informacin que poda afectar gravemente la seguridad nacional. Lo usual es asignar una etiqueta (label) a
17
cada activo con un nivel de clasificacin (por ejemplo, top secret, secret, sensitive, unclassified), y un nivel de acceso (clearance) a cada persona que deba acceder a la informacin, con la misma escala de las etiquetas. Esta visin de la clasificacin ha sido superada con el tiempo, al tener las nuevas tecnologas de comunicaciones y redes cada vez ms ingerencia en las fuerzas armadas. Hoy en da en los ambientes militares se consideran tambin requisitos de clasificacin basados en la integridad y la disponibilidad. Para ambientes no militares (comerciales, de gobierno u otras organizaciones), lo usual es asignar etiquetas a los activos (por ejemplo, confidencial, de uso interno, sensible, pblica) y establecer procedimientos para que todo el personal entienda los distintos cuidados que debe adoptar de acuerdo con la clasificacin. Es tan importante el procedimiento de clasificacin de todos los activos crticos, como as tambin la toma de conciencia y entrenamiento para saber qu hacer (y sobre todo, qu no hacer) con la informacin clasificada.
2.7 Gestin de Riesgos

Los controles de seguridad (y ms especficamente, la tecnologa asociada) son el aspecto histricamente ms visible de la Seguridad de la Informacin. Por ejemplo, la norma ISO/IEC 27002 (ex ISO/IEC 17799) es una gua de implementacin de 133 controles de seguridad, agrupados en 39 objetivos de control pretendidos. El origen de esta norma fue la BS 7799 (del British Standards Institution) que recopilaba todas las buenas prcticas existentes en Reino Unido en lo referido a Seguridad de la Informacin. Estas normas tambin contenan lineamientos muy generales sobre el anlisis y evaluacin de los riesgos como fuente para seleccionar las medidas a aplicar. Al principio, la interpretacin de la industria de la seguridad era que se contaba con una serie de medidas que se haban descubierto eficaces para controlar la mayora de las amenazas conocidas. Con el tiempo, y luego de varios proyectos fallidos de implementacin de los controles de la norma ISO 17799, se comprendi la necesidad de determinar los pasos o requisitos previos para implementar estas tcnicas de control de una manera eficaz (sabiendo dnde aplicarlas), eficiente (sabiendo con qu intensidad aplicarlas) y continua (asegurando su mantenimiento y mejora con el paso del tiempo). Dichos requisitos, que se recopilaron primero en la parte 2 de la BS 7799 (o BS 77992) y posteriormente en la norma ISO/IEC 27001, incluyen la gestin de riesgos, la gestin documental, la responsabilidad de la Direccin, las mtricas de seguridad y la mejora continua. La Gestin de Riesgos (o Risk Management) introduce el concepto de que nada es 100% seguro en materia de Seguridad de la Informacin -valga la redundancia. Se manejan conceptos como probabilidad de ocurrencia e impacto: no se sabe a ciencia cierta cundo puede ocurrir un incidente, ni cules pueden ser sus consecuencias. Lo que s podemos decir es que existe un nivel de riesgos de seguridad relacionado con las condiciones particulares que rodean las actividades de la organizacin. Las buenas prcticas normalmente utilizan definiciones muy similares a las siguientes:
18
Gestin de Riesgos: actividades coordinadas para dirigir y controlar una organizacin respecto de los riesgos de su negocio. Amenaza (threat): un hecho potencial, que de ocurrir se traduce en un incidente que puede resultar en dao para la informacin o el negocio de la organizacin (normalmente, un factor externo). Vulnerabilidad: una debilidad en un activo, grupo de activos o controles de seguridad que lo protegen, que puede ser aprovechada por una amenaza para concretarse (normalmente, un factor interno). Riesgo (risk): la combinacin de la probabilidad de ocurrencia y el impacto o consecuencia de que una amenaza se concrete (normalmente, que se conjuguen el factor externo con el interno). Control o Contramedida: una tcnica para manejar el riesgo, reduciendo la probabilidad de ocurrencia o el impacto de una amenaza. Riesgo Residual: el riesgo remanente luego de aplicar un control.
En la figura 2.3 se presenta un esquema (similar al de la figura 2.2) con la relacin entre algunos de los conceptos. Por lo general, las amenazas estn asociadas a un factor externo (o agente de amenaza) que aprovecha una vulnerabilidad inherente a los activos, controles o informacin que se est protegiendo. Conviene expresar a las amenazas en el tiempo presente del modo subjuntivo, para resaltar que se trata de un hecho que puede ocurrir con determinada probabilidad. Por ejemplo: "que la informacin sea alterada por el ingreso de un virus informtico en el sistema". De la misma forma, conviene expresar las vulnerabilidades en el tiempo presente o pasado del modo indicativo. Por ejemplo: No se instal un sistema antivirus. Normalmente las vulnerabilidades se asocian a una falla en los controles, pero tambin pueden deberse a una caracterstica intrnseca del activo. Por ejemplo: El sistema abarca una gran variedad de tecnologas, dificultando la deteccin y tratamiento de bugs en las aplicaciones, o tambin Por requerimientos regulatorios la informacin debe almacenarse en papel, por lo que puede ser afectada por agua, fuego o humedad. La gestin de riesgos es una de las principales actividades de planificacin en la gestin de la Seguridad de la Informacin. Reconocemos de manera explcita que nuestro esfuerzo de proteccin de la informacin depende de factores en general ajenos a nosotros (amenazas), factores internos (nuestras vulnerabilidades), y que nuestra respuesta puede reducir (pero no eliminar) los riesgos asociados. El proceso de Gestin de Riesgos normalmente incluye 3 etapas que trataremos en las secciones que siguen: Anlisis de Riesgos (o Risk Analysis) Evaluacin de Riesgos (o Risk Evaluation) Tratamiento de Riesgos (o Risk Treatment)
19
Controles y Contramedidas de Seguridad Activos
Amenazas
Vulnerabilidades
Figura 2.3 En todo momento, debe tenerse en cuenta que si bien la gestin de riesgos involucra a especialistas en la materia, es un proceso que requiere de la participacin activa de todas las reas de la organizacin, ya que en ltima instancia, son stas quienes poseen el conocimiento sobre el negocio, y sobre las amenazas y vulnerabilidades que lo aquejan. Que las reas sean quienes estn ms relacionadas con el negocio y por lo tanto conozcan mejor que nadie las amenazas, no implica que la gestin de riesgos deba quedar librada a su decisin solamente. Todo lo contrario, volviendo sobre la negociacin entre dueos y custodios, debe existir una tercera parte que gue este proceso (normalmente los analistas o administradores de seguridad). Por ltimo, la Alta Direccin debe apoyar la gestin de riesgos, permitiendo a las reas invertir recursos y tiempo en las actividades requeridas, y aceptando formalmente los riesgos residuales. 2.7.1 Anlisis de Riesgos El Anlisis de Riesgos es el uso sistemtico de la informacin para identificar fuentes de riesgo y calcular sus valores en funcin a la probabilidad de ocurrencia y el impacto. El factor de impacto del riesgo se basa en la tasacin o valoracin que tiene el activo para la organizacin, ya que identifica el grado de dao y las consecuencias producidas cuando una amenaza se concreta. A mayor valoracin del activo, mayor el impacto, y viceversa. El factor de probabilidad del riesgo se basa en la probabilidad de que una amenaza se concrete. Normalmente, para la concrecin se dan dos condiciones: existe algn factor externo (tambin llamado agente de
20
amenaza) que aprovecha un factor interno (relacionado con alguna vulnerabilidad en el activo o los controles). La probabilidad de ocurrencia de la amenaza depende entonces de la probabilidad de la aparicin del factor externo, junto con la probabilidad de que ese factor externo aproveche alguna vulnerabilidad. El proceso de Anlisis de Riesgos normalmente incluye: Identificacin de activos de la organizacin. Tasacin o valorizacin de los activos. Identificacin de controles ya implementados. Identificacin de las amenazas y su probabilidad de ocurrencia. Identificacin de las vulnerabilidades y probabilidad de ser aprovechadas por las amenazas. Estimacin del impacto de las amenazas sobre los activos. Estimacin de la magnitud del riesgo en funcin de las probabilidades de ocurrencia e impactos calculados.
Las formas posibles para combinar la probabilidad de ocurrencia con el impacto son muchas, pero siempre con la premisa de que el nivel de riesgo calculado debe aumentar si cualquiera de esos dos factores de contribucin aumenta. Existen dos enfoques generales en el Anlisis de Riesgos: el cuantitativo y el cualitativo. 2.7.2 Anlisis de Riesgos Cuantitativo En el Anlisis de riesgos cuantitativo, se utiliza informacin estadstica para calcular al riesgo como un valor promedio, o valor esperado13. En general se trata de un valor monetario que expresa cunto dinero, en promedio, podemos esperar perder a lo largo de un perodo determinado. La matemtica detrs del anlisis cuantitativo puede ser tan sofisticada como queramos, pero en algunas situaciones puede simplificarse bastante. Por ejemplo, cuando la amenaza considerada ocurre con una frecuencia conocida, y cada vez que ocurre el impacto monetario es el mismo (y conocido), se utiliza, por un lado, la tasa de ocurrencia anual (ARO o Annualized Rate of Occurrence) de la amenaza para estimar la probabilidad de ocurrencia; y por el otro, el valor monetario de la prdida para estimar el impacto (SLE o Single Loss Expectancy). El riesgo se expresa directamente como la multiplicacin de ambos factores, obtenindose el costo anual esperado causado por esa amenaza (ALE o Annualized Loss Expectancy). Consideremos un ejemplo de anlisis cuantitativo: 1. El activo que protegemos son los datos de la tarjeta de los clientes de la organizacin.
13
Segn la norma BS 25999-1:2006: El riesgo es generalmente cuantificado como un efecto promedio, sumando el efecto combinado de cada posible consecuencia, pesada de acuerdo con la probabilidad asociada de cada consecuencia, para obtener un valor esperado. Eso no es ni ms ni menos que la esperanza matemtica o media de la distribucin de probabilidad de las prdidas ocasionadas por una amenaza (en general expresadas en trminos monetarios).
21
2. La amenaza que estamos considerando es la divulgacin por robo de la laptop de un consultor que almacenaba una parte de dicha informacin14. 3. El valor del activo lo estimamos en unos $400.000. 4. El porcentaje de registros generalmente contenidos en un laptop es de un 25% (esto se llama Factor de Exposicin, EF, o Exposure Factor) 5. El impacto de la amenaza se calcula multiplicando el valor del activo por el factor de exposicin: SLE = EF x Valor del Activo = $100.000 (perdemos el 25% de un activo valuado en $400.000). 6. La probabilidad de ocurrencia se estima con datos estadsticos: ARO = 0,25 (segn la estadstica de la industria, o propia de la organizacin, se roba una laptop cada cuatro aos)15. 7. El riesgo calculado (expresado monetariamente) es: ALE = ARO x SLE = $25.000 (en promedio, es lo que esperamos perder en un ao por el robo de laptops a consultores). Como veremos ms adelante, expresar los riesgos de manera monetaria tiene la ventaja de que podemos comparar ese valor con el costo de las contramedidas que lo mitigan. Hasta podemos calcular un retorno de inversin de la seguridad. Sin embargo, el enfoque cuantitativo tiene varios puntos flacos. Para empezar, el clculo anterior slo tiene sentido en amenazas con estadsticas conocidas (aparicin de virus, worms, desastres naturales, riesgo comercial, etc.). Existen algunos tipos de incidentes que sencillamente a las organizaciones no les gusta reconocer (fraude interno, divulgacin de informacin de clientes) a menos que sea absolutamente imprescindible. Otros tipos de incidente no ocurren lo suficientemente seguido como para estimar la probabilidad en forma confiable, sobre todo aquellos incidentes de baja probabilidad de ocurrencia, pero alto impacto16. Por otro lado, est el problema de la estimacin del impacto en trminos econmicos. En el ejemplo dijimos que lo estimbamos en $400.000, pero no cul era la interpretacin de esa cifra. Se trata de la suma de todos los lmites de crdito de los clientes? Se trata del impacto financiero sobre la organizacin en indemnizaciones? Se trata de la variacin del valor de la accin si la organizacin cotiza en bolsa? El tpico error cuando usamos un enfoque cuantitativo es utilizar un modelo incompleto que no incorpore todas las variables que debera, y que en consecuencia estiman un impacto menor al real. A veces, directamente, no se puede calcular en trminos monetarios, porque el modelo que usamos es incompleto, o inaplicable. Muchos autores sostienen que el mtodo ALE es solamente una forma elegante de acomodar los nmeros para que digan lo que queremos que digan17.
14
Muchos se preguntarn en qu circunstancia puede ser razonable que un consultor almacene en su laptop la informacin de tarjetas de crditos de los clientes. Yo me pregunto lo mismo, pero lamentablemente, es un ejemplo que he tomado de las noticias de las publicaciones especializadas en seguridad. Ocurre muy a menudo. 15 Aclaro, por si hace falta, que este dato es absolutamente inventado para el ejemplo. 16 Para una muy buena explicacin de por qu ALE sencillamente no es bueno, ver Jaquith, Andrew: Security Metrics: Replacing fear, uncertainty, and doubt, Upper Saddle River (NJ), Addison-Wesley, 2007, pgs. 31 a 36. 17 Op. cit.
22
2.7.3 Anlisis de Riesgos Cualitativo En el Anlisis de riesgos cualitativo cambia la forma de estimar las componentes, utilizndose el juicio, experiencia e intuicin de expertos y personas involucradas en los procesos del negocio. Se utilizan tcnicas como Delphi, brainstorming, focus groups, cuestionarios, checklists y entrevistas para obtener los resultados, y los valores se expresan como nmeros enteros (escalas de 1 al 5, como promedios de tales valores, con las palabras Alto, Medio, Bajo, etc.). Existen muchas maneras de combinar la probabilidad de ocurrencia y el impacto para calcular el riesgo en un anlisis cualitativo, probablemente tantas como organizaciones haya. Una de ellas es usando matrices predefinidas con entradas para el nivel de amenaza (factor externo), el nivel de vulnerabilidad (factor interno) y valor del activo, y como salida, el valor estimado de riesgo. En la figura 2.4 se muestra un ejemplo. En ese contexto, una amenaza que tenga una probabilidad media de ocurrir (nivel de amenaza, por ejemplo, un virus informtico), y que aproveche una vulnerabilidad para la que la organizacin no est bien preparada (nivel de vulnerabilidad, por ejemplo, un equipo conectado en forma directa a internet y que carece de protecciones antivirus) va a resultar en un valor de riesgo de 3, 4 o 5 (en una escala del 1 al 7) dependiendo del valor del activo considerado (mientras mayor sea el valor, mayor el valor del riesgo). Otra forma es calculando el riesgo como una multiplicacin de dos factores, utilizando una escala numrica. En la figura 2.5 se muestra un ejemplo, donde la probabilidad de ocurrencia y el impacto de una amenaza adoptan valores entre 1 y 10, y el riesgo asociado lo hace entre 1 y 100. En este caso, la interpretacin del riesgo es un rea rectangular en un grfico de dos dimensiones.
Valor del Activo Bajo Medio Alto
Nivel de Amenaza (factor externo) Bajo Medio Nivel de Vulnerabilidad (factor interno) Bajo Medio Alto Bajo Medio Alto 1 2 3 2 3 4 2 3 3 3 4 5 3 4 5 4 5 6 Figura 2.4
Alto Bajo 3 4 5 Medio 4 5 6 Alto 5 6 7
Un punto importante a tener en cuenta es que, ya sea que se use una matriz como la de la figura 2.4 o se represente al riesgo como un rea como en la figura 2.5, los valores numricos empleados no tienen un significado en s mismos, como en el caso del anlisis cuantitativo. El valor calculado del riesgo slo tiene sentido en la medida en que se lo compare contra otros riesgos, o contra una escala preestablecida.
23
Impacto
10 8 6 4 2 2 4 6 8
Riesgo Amenaza1 2x10=20
10
Probabilidad de Ocurrencia
Figura 2.5 El anlisis cualitativo de la figura 2.5 puede parecer sencillo a simple vista. El desafo viene con la cantidad de activos y amenazas que deben manejarse, y por el hecho de que los riesgos son estimados por diferentes personas en la organizacin. El proceso requiere de mucha coordinacin por parte de un especialista en riesgos que rena toda la informacin producida por las partes, logre una visin consensuada entre los distintos dueos y custodios, y presente un anlisis integral para que la Alta Direccin entienda el significado y pueda tomar las acciones adecuadas. Considrense los resultados de un ejercicio real de Gestin de Riesgos18. Los resultados se presentan con la forma de un grfico de burbujas en la figura 2.6. Las escalas numricas utilizadas son iguales que las de la figura 2.5. El tamao de cada burbuja es proporcional a la cantidad de amenazas con los mismos niveles de riesgo. Para entender el esfuerzo que le requiri a la organizacin, pensemos que el proceso involucr el trabajo de 8 reas funcionales y dur alrededor de 3 meses, incluyendo, adems del Anlisis de Riesgos, la Evaluacin y el Tratamiento. Las reas tuvieron que identificar (y describir) 69 activos, 101 amenazas, y otras tantas vulnerabilidades. Adems, para cada activo, se pidi que se identificaran (y se evaluaran la eficacia de) los controles ya implementados. Los valores de Impacto y Probabilidad de Ocurrencia se calcularon estimando los niveles de 5 variables para cada amenaza (la probabilidad de aparicin de las amenazas, el nivel de vulnerabilidad, y los impactos sobre confidencialidad, integridad y disponibilidad). Para las 5 variables solamente se pidi que se identificaran tres niveles: alto, medio, o bajo19. An as, la cantidad de variables que debieron consensuarse entre dueos, custodios y administradores de seguridad fue de 505, solamente para el Anlisis de Riesgos.
18
En una empresa mediana de servicios del rubro bancario en la que particip como consultor. 19 Creo que no puedo remarcar con el suficiente nfasis que estamos hablando de un ejemplo tomado de la vida real, pero que cada organizacin puede seleccionar otras escalas, otras variables, e incluso, otra manera de combinarlas.
24
10,0 8,0
1 1 3
1 1 2 7 5 12 11 1 5 5 2 5 4 2 5 1
Impacto
6,0 4,0
5 4 4
2,0
2,0
4,0
6,0
8,0
10,0
Probabilidad de Ocurrencia Figura 2.6 2.7.4 Evaluacin de Riesgos El propsito de la Evaluacin de Riesgos es identificar el significado que los riesgos calculados tienen para la organizacin y jerarquizarlos por importancia. El grupo que realiza la evaluacin de riesgos debe ser multidisciplinario, con participantes de distintas reas de la organizacin. sta debe cerciorarse de que los propietarios de los activos involucrados estn presentes en el proceso. Se deben comparar los niveles calculados de riesgo con una escala de riesgo establecida especialmente para dicho efecto, con la finalidad de decidir qu medidas se van a implementar en la etapa de tratamiento de riesgo. Los criterios que usualmente se utilizan para efectuar la evaluacin son: Impacto econmico del riesgo. Tiempo de recuperacin de la empresa. Probabilidad de ocurrencia del riesgo. Probabilidad de interrumpir las actividades de la empresa.
En el caso de los riesgos analizados en forma cuantitativa, la evaluacin es ms sencilla, en principio, porque el significado de los niveles de riesgo ya tienen una interpretacin: se trata del dinero que la organizacin espera perder a causa de una amenaza determinada. El criterio consiste simplemente en comparar el costo de implementacin de las posibles contramedidas, y el ahorro monetario producido. Para ilustrar estos conceptos, consideremos el ejemplo de anlisis cuantitativo ya utilizado: 1. Como ya se estableci, el riesgo sin contramedidas es: ALE0 = $25.000 2. Se considera una contramedida que involucre la encripcin de la informacin, que consigue disminuir el riesgo a un valor inferior: ALE1 = $5.000
25
3. El costo de la contramedida, en la forma de licencias de software, se puede expresar anualmente como: Costo1 = $10.000 4. Con estos datos, se puede calcular el ahorro que produce la aplicacin de la contramedida (la instalacin de la herramienta de encripcin): Ahorro1 = ALE0 ALE1 Costo1 = $10.000 5. El Retorno de Inversin en Seguridad (o ROSI, Return on Security Investment) se calcula de la misma manera que se calcula un ROI: ROSI = Ahorro / Costo = $10.000 / $10.000 = 1 Lo que significa que por cada peso invertido, se obtiene otro peso como ahorro. 6. El criterio de evaluacin consiste en elegir aquella contramedida (puede haber ms de una opcin!) que tenga un mejor ROSI 7. Si el ROSI < 0 entonces se acepta el riesgo, porque la contramedida es ms cara que el ahorro Nuevamente, debemos destacar que el anlisis cuantitativo slo tiene sentido para amenazas bien estudiadas, con abundante estadstica, y cuando las consecuencias de la concrecin de la amenaza son realmente conocidas20. En el caso del anlisis cualitativo, la organizacin debe empezar por definir cul es el significado de los distintos niveles que el riesgo puede adoptar en trminos que tengan sentido para el negocio. Por ejemplo, en el grfico de la figura 2.6, qu significado tiene la burbuja que se ubica en las coordenadas (6,6), con un riesgo calculado de 36 sobre 100? Y la burbuja en (10,6)? Es equivalente ese nivel de riesgo de 60 con el de la burbuja en (6,10)? Requieren del mismo tipo de tratamiento, ya que cuentan con el mismo nivel de riesgo? La interpretacin se hace en funcin de los valores asignados por las reas a las 5 variables mencionadas en la seccin anterior21. Son las propias reas funcionales de la organizacin que identificaron dichos valores las que asignan un significado concreto a las coordenadas del riesgo. Por ejemplo, en el ejercicio bajo anlisis, una amenaza cuya probabilidad de ocurrencia sea media, pero que la probabilidad de que se aproveche de las vulnerabilidades de la organizacin para su concrecin sea alta da como resultado que la coordenada probabilidad de ocurrencia de la figura 2.6 adopte el valor 6. Para asignarle significado al impacto, se usan las otras tres variables: por ejemplo, una amenaza que si se concreta tiene un impacto alto en confidencialidad, medio en integridad, y bajo en disponibilidad, da como resultado que la coordenada impacto tambin adopte el valor 6.
En todas las conferencias en las que expuse el tema de la evaluacin de riesgos, siempre surgi, palabras ms, palabras menos, la siguiente pregunta en el auditorio: qu pasa cuando el ahorro no justifica el control, pero en realidad un incidente de ese tipo est poniendo en riesgo la credibilidad de la organizacin frente a los clientes?. Mi respuesta es siempre la misma: hicimos mal el anlisis de riesgos en primer lugar, porque el impacto econmico es evidentemente mayor al calculado. 21 Vale aqu la misma aclaracin que en la seccin anterior, se trata del ejemplo de una posible metodologa entre varias que puede elegir una organizacin.
20
26
La interpretacin del nivel de riesgos es importante para que la organizacin determine qu amenazas son aceptables, y cules no. Normalmente se lo hace fijando un umbral de riesgo mximo tolerable, por encima del cul las amenazas deben recibir un tratamiento. Ese nivel particular de riesgo es el que ms importa interpretar. Dicho umbral depende de apetito de riesgo de la organizacin. Existen negocios que deben aceptar un nivel general de riesgos mayor que otras. Por ejemplo, en trminos generales, un sitio de Internet dedicado a las recetas de cocina probablemente acepte un umbral de riesgos aceptables mayor que un sitio que maneje informacin personal de los usuarios. Consideremos el umbral de riesgos aceptables de la figura 2.7, que sigue en lnea con lo mostrado en la figura 2.5 de la seccin anterior. En ese caso, hemos considerado que un nivel de riesgos de 16 es aceptable, todas las amenazas cuyos niveles de riesgo calculados se encuentren dentro del rea demarcada son aceptables para la organizacin.
Impacto
10 8
Mximo Riesgo Aceptable 16
6 4 2 2 4 6 8 10 Riesgo Amenaza2 8x6=48
Probabilidad de Ocurrencia
Figura 2.7 Tal vez un mejor mtodo que el anterior para evaluar si el riesgo es aceptable o no, sea utilizar un rea de riesgo aceptable, como se muestra en la figura 2.8. En este caso el mximo riesgo aceptable tambin es 16, pero se evalan ambas componentes (probabilidad de ocurrencia e impacto) por separado y ninguna puede superar el valor de 4. Tratar a las componentes por separado a veces es preferible a simplemente tratar de disminuir los riesgos, porque pone de manifiesto qu aspecto de la amenaza conviene tratar. No es lo mismo reducir el impacto de una eventual amenaza, que su probabilidad de ocurrencia, como veremos en las secciones posteriores.
27
Impacto
10 8
rea de Riesgo Aceptable 4x4
6 4 2 2 4 6 8 10 Probabilidad de Ocurrencia Riesgo Amenaza2 8x6=48
Figura 2.8 Siguiendo con el ejercicio real, la organizacin se decidi por un rea de riesgo aceptable de 1,8 (sobre 10) para la probabilidad de ocurrencia, y 2,2 (sobre 10) para el impacto. El riesgo equivalente aceptable era de 3,96 (sobre 100). El significado de aceptar 1,8 para la componente de probabilidad de ocurrencia era que una amenaza poda tener una probabilidad media de aparicin, siempre que la probabilidad de que encontrase una vulnerabilidad fuese baja; o bien, que si la probabilidad de aparicin era baja, entonces la probabilidad de aprovecharse de una vulnerabilidad poda ser media. Con respecto al componente del impacto de la amenaza, el valor aceptable por debajo de 2,2 implica que tanto en confidencialidad, integridad o disponibilidad el impacto es bajo. En el grfico de la figura 2.6 se observa que de las 101 amenazas identificadas solamente 20 eran aceptables a priori. Unas ltimas consideraciones sobre la evaluacin de riesgos cualitativa. Por un lado, no es una actividad que se desarrolle despus del anlisis, sino al mismo tiempo. Por el otro, deben definirse exactamente qu se entiende por los niveles de probabilidad e impacto definidos. Esto es necesario para homogeneizar el resultado del anlisis y evaluacin de los riesgos y disminuir la componente de juicio individual de los involucrados. Por ejemplo, puede entenderse que impacto alto significa imposibilidad de brindar nuestro servicio, impacto medio significa que brindamos el servicio, pero no estamos en condiciones de facturarlo, e impacto bajo significa que no podemos adquirir nuevos clientes; otra alternativa es definir conjuntos de sistemas o informacin de impacto Alto, Medio, Bajo a priori, en funcin a la cercana con las actividades principales del negocio. Del mismo modo puede definirse probabilidad alta significa que el evento ocurre ms de una vez al mes, etc. 2.7.5 Tratamiento de Riesgos Una vez que el riesgo ha sido evaluado y la organizacin ha determinado cules son los activos de la informacin sujetos a riesgos, y cul es su significado, debe elegir una estrategia para su tratamiento. La Alta Direccin
28
debe analizar dos factores principales al tomar la decisin sobre tratamiento de riesgos: El posible impacto si la amenaza ocurre. La probabilidad de ocurrencia de la amenaza.
Al margen de considerar el impacto financiero del riesgo en la organizacin, sta debe considerar el costo de actuar sobre alguna de las opciones del tratamiento del riesgo. La organizacin debe asegurarse de que existe un buen balance entre el costo de la proteccin y el valor de los activos protegidos, para no perjudicar la rentabilidad ni la competitividad de la empresa. Para el tratamiento del riesgo las buenas prcticas consideran cuatro estrategias genricas: Reduccin del riesgo: aplicacin de controles sobre los activos que disminuyen el riesgo. La reduccin del riesgo normalmente se elige cuando los controles a implantar para disminuir los riesgos a los niveles de aceptacin previamente identificados por la empresa son econmicamente factibles. Aceptacin del riesgo: la Alta Direccin entiende el riesgo y explicita su aceptacin en un documento formal. La aceptacin del riesgo normalmente se elige cuando el diseo del control para mitigar el riesgo es ms costoso que las consecuencias del riesgo. Sin embargo, debe resaltarse el hecho de que esta opcin implica entender y aceptar las consecuencias de la concrecin de una amenaza en forma objetiva y con conocimiento. Transferencia del riesgo: traslado del riesgo a terceras partes, por ejemplo, mediante una tercerizacin de los controles, o la contratacin de un seguro. La transferencia del riesgo normalmente se elige cuando el diseo del control para mitigar el riesgo es costoso, pero las consecuencias del riesgo son devastadoras para la empresa y la transferencia del riesgo es econmicamente viable. Evasin del riesgo: cese de las actividades que producen los riesgos. La evasin del riesgo normalmente se elige cuando el diseo del control para mitigar el riesgo es costoso, las consecuencias del riesgo son devastadoras para la empresa, pero la transferencia del riesgo no es econmicamente viable.
Algunos autores aceptan una quinta estrategia que es la negacin del riesgo (denial), pero es ms bien una forma de describir lo que no debe hacerse (pero que algunas organizaciones hacen), la no-estrategia, o la estrategia de las malas prcticas 22. El riesgo residual es el riesgo remanente luego de haber implementado las decisiones tomadas en el tratamiento del riesgo. La Alta Direccin debe asegurarse de que entiende estos riesgos residuales y de que el nivel de riesgos residuales se encuentra dentro de los parmetros aceptables.
22
Ver por ejemplo, Harris, Shon: CISSP Certification, All-In-One Exam Guide, Second Edition, Emeriville, McGraw-Hill, 2003.
29
Volviendo al ejemplo de una gestin de riesgos real en una organizacin, en la figura 2.9 se muestra el grfico de riesgos residuales propuestos a la Alta Direccin. Ntese que de las 101 amenazas identificadas, 19 han quedado por fuera del rea de riesgo aceptable, y el grfico es ms parecido al de la figura 2.7 que al de la figura 2.8. Los valores de los riesgos han disminuido sensiblemente, pero en algunos casos, sencillamente era imposible disminuir los valores del impacto o de la probabilidad de ocurrencia, y la organizacin no tuvo ms remedio que aceptarlos de manera consciente y objetiva.
10 8
Impacto
6 4
2 1
2 2
1 1 4 1
3 1 2 54 28
10
Probabilidad de Ocurrencia Figura 2.9 La etapa del tratamiento de riesgos es la ms difcil de llevar a la prctica, porque es en la que debemos hacer cosas. En las dos etapas anteriores, relevbamos informacin, realizbamos una serie de reuniones de trabajo en grupo y llegbamos a conclusiones. Como las condiciones en las que est inmersa la organizacin (y su negocio) no se mantienen estticas en el tiempo, los riesgos se modifican constantemente, y tambin debe hacerlo su anlisis, evaluacin y tratamiento. En consecuencia, el proceso de gestin de riesgos debe ser implementado en forma peridica. En todo momento, los datos que utilizamos en los grficos se estn modificando, y la organizacin debe mantener la claridad con respecto a las sucesivas etapas de anlisis, evaluacin e implementacin de controles. Por ejemplo, en el caso de los controles que actan sobre los riesgos, tenemos los controles ya implementados, los que queremos implementar, y los que se estn implementando. De igual manera, tenemos los riesgos residuales propuestos (antes de que implementemos los controles) y los reales (si es que podemos medirlos de manera independiente, una vez implementados los controles). Estos riesgos residuales reales, se convierten luego el los riesgos calculados en un posterior anlisis de riesgos. Gestionar estas variables y su evolucin a lo largo del tiempo constituye un desafo importante.
30
Deberamos esperar que el grfico real de los riesgos de la organizacin vaya evolucionando de la situacin inicial de la figura 2.6 hacia la de la figura 2.9 (si todo sale de acuerdo a lo planeado). Sin embargo, es posible que cuando la organizacin comience nuevamente el ciclo de gestin de los riesgos, habrn aparecido nuevos activos que cuidar y nuevas amenazas, y tal vez la eficacia de algunos controles establecidos no habrn sido los que se esperaban, por lo que el riesgo analizado sigue estando en un valor por encima del umbral de aceptacin.
2.8 Controles y Contramedidas

A lo largo del libro utilizaremos en forma intercambiable las palabras controles y contramedidas: son las actividades, tecnologa, tcnicas y conocimiento que aplicamos para modificar los valores del riesgo con el objetivo de controlar las amenazas a los activos de informacin. En trminos generales, existen tres tipos de controles: Controles fsicos: por ejemplo, una cerradura, un guardia de seguridad, un perro, iluminacin, una cerca, etc. Controles tcnicos o lgicos: relacionados con la tecnologa y sistemas de la informacin, como por ejemplo, un firewall, IPS, el uso de encripcin, etc. Controles administrativos: relacionados con las actividades y pautas cumplidas por las personas, como por ejemplo, un procedimiento de aprobacin, una medida disciplinaria, una poltica de seguridad, un checklist de seguridad, etc.
Ningn control cae exclusivamente en una de las categoras, pues todos los controles tienen los tres aspectos en distintas proporciones. Los controles tambin se pueden clasificar de acuerdo con el tipo de funcionalidad (o tipo de proteccin) que proveen: Controles preventivos: detienen o evitan eventos no deseados. Controles detectivos: identifican eventos no deseados que han ocurrido. Controles correctivos: corrigen las causas y/o consecuencias de eventos no deseados. Controles disuasivos: desalientan violaciones de seguridad. Controles de recupero: recuperan recursos y capacidades de la organizacin luego de un incidente. Controles compensatorios: proveen alternativas a otros controles dbiles o muy costosos para implementar.
La funcionalidad est muy relacionada con el tratamiento de los riesgos, ya que define qu aspectos del riesgo se van a mitigar. Por ejemplo, para tratar el riesgo de una amenaza con baja probabilidad de ocurrencia, pero alto impacto, lo ms conveniente ser algn control correctivo o de recupero antes que uno preventivo, ya que antes de disminuir an ms la probabilidad de
31
ocurrencia, sera mejor primero intentar prepararse para cuando ocurra el incidente. Debemos cuidarnos de mitigar los aspectos equivocados de una amenaza. Los controles de acceso son un tipo especial de controles que se aplican sobre el acceso a la informacin y a los activos, incluyendo tecnologa de autenticacin y autorizacin de usuarios, y permisos sobre archivos, redes, y sistemas de informacin, entre otros. Histricamente, los controles de acceso han concentrado las actividades operativas ms importantes para la Seguridad de la Informacin: por ejemplo, la gestin de usuarios y contraseas, o la asignacin de permisos sobre archivos y aplicaciones. Algunos lineamientos de buenas prcticas para su aplicacin son: Need to know: la informacin debe ser accedida por personas o entidades que tengan un motivo vlido para hacerlo, en funcin de las clasificaciones y niveles de acceso. Mnimo Privilegio: el acceso o manipulacin de la informacin debe darse en forma restrictiva, no como la norma, sino como una excepcin. Por defecto, ninguna persona o entidad debe tener asignado ms permisos que los estrictamente necesarios.
Por ltimo, existen aspectos organizacionales que deben tenerse en cuenta para aplicar controles con mayor probabilidad de xito: Seguridad por Capas: la probabilidad de que una amenaza logre aprovechar una vulnerabilidad disminuye si debe atravesar ms de un control en forma secuencial. Concientizacin en Seguridad (Security Awareness): capacitacin y entrenamiento en el uso correcto y proteccin de la informacin y los activos de la empresa. Separacin de Tareas (Separation of Duties): divisin de las tareas crticas de la organizacin en sub-tareas asignadas a ms de una persona, para que la concrecin de determinadas amenazas (por ejemplo, fraude) requieran de la connivencia de varios. Rotacin de Funciones (Job Rotation) y Vacaciones Obligatorias (Mandatory Vacations): rotacin peridica de la gente que realiza determinadas funciones crticas, para aumentar la probabilidad de que se descubran conductas inapropiadas. Registro de Responsabilidad (Accountability): mantener un historial (protegido) de quin hizo qu cosa, con qu activos, y cundo (puede ser un control disuasivo o detectivo).
Todos estos aspectos estn relacionados con las personas y los procesos de una organizacin, y complementan los aspectos tecnolgicos. Cualquier control tcnico puede ser vulnerado sin una correcta gestin de los aspectos ms administrativos.
2.9 Roles y Responsabilidades
32
Las buenas prcticas establecen una serie de roles y responsabilidades referentes a la gestin de la Seguridad de la Informacin. Los ms importantes son: Alta Direccin: define directrices, establece responsabilidades y provee los recursos necesarios. Sobre la importancia del involucramiento y apoyo de la Alta Direccin ya se habl en la seccin 2.4. Dueo de la informacin: responsable ltimo y (generalmente) productor de la informacin o activos (normalmente, son los diferentes gerentes de lnea). Custodio: responsable por la implementacin correcta de los controles. Se trata de una funcin delegada por el dueo (normalmente, es el gerente de tecnologa). Oficial de Seguridad: quien gestiona los aspectos del da a da de la Seguridad (puede incluir ms o menos capacidad operativa, segn el caso) Auditor: quien evala en forma independiente la gestin de la seguridad y los controles implementados Usuario: quien accede a la informacin para realizar sus funciones dentro de la organizacin. Debe cumplir con las polticas y procedimientos establecidos. Algunas veces los usuarios son los propios dueos de la informacin.
La gobernabilidad del esfuerzo de seguridad depende en gran medida de que las partes logren una buena comunicacin y comprensin mutua. La seguridad en una organizacin implica la necesidad de compatibilizar necesidades distintas (y a veces contrapuestas), y homogeneizar conocimiento distribuido. Se trata de una importante negociacin interna, que adems est inserta dentro del da a da operativo de cada una de las reas. Quien realmente conoce el valor para el negocio que tiene la informacin en cuestin (el dueo), no necesariamente est capacitado para entender los costos o los detalles de la implementacin de las medidas de seguridad (los custodios), o el conocimiento metodolgico necesario para evaluar amenazas y vulnerabilidades (el oficial de seguridad). Por ejemplo, los dueos muchas veces caen en la tentacin de asignar el mximo valor a todos los activos e informacin de los que son responsables, pero los custodios estn ms interesados en poder asignar de manera eficiente los recursos invertidos en la operacin de las medidas de proteccin (bsicamente ahorrar tiempo y dinero). Por otro lado, quien tiene una preparacin metodolgica en seguridad (el oficial de seguridad) en general no puede conocer los procesos de negocio al nivel en que lo hace el dueo, ni entender la carga operativa total que tienen que manejar los custodios. Su tarea debe limitarse a la facilitacin del proceso de negociacin interna, descubrimiento de situaciones que requieren atencin y determinacin de si se estn cumpliendo o no los objetivos y pautas de seguridad. Un caso particular representan los auditores (internos, externos, de sistemas, etc.). Muchas veces se confunde sus funciones con las de un oficial de seguridad, pero la funcin de la auditora es asegurar una mirada
33
independiente de la implementacin de las tcnicas y herramientas de seguridad, incluyendo los procesos de gestin. Las capacidades tcnicas pueden (y muchas veces, deben) ser similares, pero los auditores no pueden estar involucrados en la implementacin, para evitar conflictos de intereses. Por ejemplo, la auditora contable es un requisito legal anual para asegurar que el balance presentado a los accionistas y dems partes interesadas es preciso (la informacin es ntegra) y que sus decisiones estn bien fundamentadas. Por ltimo, estn las necesidades de los usuarios de la informacin. Ellos necesitan la informacin para (ni ms ni menos) desarrollar el negocio de la organizacin. Por lo tanto, debe existir un proceso de toma de conciencia para que stos entiendan por qu existen controles de seguridad sobre la informacin, y el entrenamiento suficiente para saber utilizarlos. Las medidas de seguridad no deben entorpecer las actividades operativas de los usuarios ms all de lo razonable (nuevamente, la toma de conciencia), o stos terminarn por desactivarlas, ya sea de manera formal (justificando su caso ante la Alta Direccin), o informal (encontrando la manera de saltear los controles).
2.10 Documentacin
Segn la norma ISO 900023, la documentacin en una organizacin permite la comunicacin del propsito y la coherencia de la accin. Entre los aportes mencionados por dicho estndar sobresalen el de proveer la formacin apropiada (a las personas); el de la repetibilidad y la trazabilidad; y el de proporcionar evidencia objetiva. Todas estas caractersticas, de una u otra forma, ya han sido mencionadas en la seccin 2.8, especialmente en lo concerniente a los aspectos relacionados con las personas (que requieren entrenamiento y toma de conciencia) y los controles administrativos (que requieren repetibilidad y trazabilidad, o registro de responsabilidad). Respecto de la comunicacin de propsito, la principal forma es a travs del establecimiento de la Poltica Corporativa de Seguridad. No debera extraarnos, entonces, que uno de los pilares de las normas ISO sea el establecimiento de una poltica (de Calidad si se trata de ISO 9001, de Seguridad de la Informacin, si se trata de ISO/IEC 27001, o Ambiental, si se trata de ISO 14001). Los tipos de documentacin utilizados para la gestin de la Seguridad de la Informacin pueden ser de lo ms variados. En general, la clasificacin de la documentacin de acuerdo con el tipo de documento se muestra grficamente en una pirmide documental como la de la figura 2.10. El nombre, funcionalidad y contenido de los escalones de la pirmide puede variar de organizacin en organizacin, y la que se muestra en la figura es solamente un ejemplo tomado de un caso real. Un esquema documental debera identificar qu documentos son ms o menos especficos en cuanto a lo
ISO 9000:2005 - Sistemas de Gestin de la Calidad - Fundamentos y Vocabulario, Suiza, ISO, 2005 (traduccin certificada), seccin 2.7.1.
23
34
operativo, cules contienen el qu se quiere o se debe o se va a hacer en la organizacin, y cules contienen el cmo se va a conseguir lo anterior. A medida que se escala cada nivel de la pirmide debera requerirse un nivel creciente de aprobacin dentro de la organizacin (por ejemplo, una Poltica debera ser aprobada por la Alta Direccin, mientras que un Instructivo de Trabajo podra ser aprobado por quien va a llevar a cabo la funcin, o su supervisor). El nivel en la pirmide tambin da una idea de la frecuencia con la que se realizarn modificaciones al documento.
Menos especfico Qu Directrices Polticas
Metodologa
Polticas Funcionales Manuales, Planes y Procedimientos
Instrucciones y pasos a seguir
Caractersticas y detalles
Estndares e Instructivos
Cmo Quin Ms especfico
Evidencia
Registros
Figura 2.10. Un ejemplo de pirmide documental Existe una serie de documentos o tipos de documentos que las buenas prcticas recomiendan considerar para gestionar la Seguridad de la Informacin en la organizacin24: Poltica Corporativa: es un documento firmado por la Alta Direccin, sin demasiadas precisiones operativas y en el que debe quedar en claro una intencin o direccin de hacia dnde quiere ir la organizacin en materia de seguridad. Debera revisarse con una periodicidad cercana a la anual, pero puede modificarse con una periodicidad menor. Adems de una Poltica Corporativa de Seguridad de la Informacin, pueden existir polticas de Continuidad del Negocio, de Privacidad, de Seguridad Personal, entre otras, de acuerdo con la industria en la que se desenvuelve la organizacin. Polticas Funcionales: son polticas de menor nivel que una poltica corporativa. Tal vez atadas a un proceso particular, o una tecnologa. Por ejemplo, una Poltica de Control de Accesos, Poltica de Uso de Internet,
Los nombres pueden variar de los de la figura 2.10, acentuando el hecho de que son meros ejemplos y que las organizaciones deben definir su documentacin segn sus necesidades. En particular, la terminologa utilizada aqu es bastante compatible con las normas ISO.
24
35
etc. Su alcance es ms acotado, y si bien hay un listado de qu debemos o no debemos hacer, existe un cmo implcito en dicho alcance (por ejemplo, una Poltica de Uso de Internet claramente se refiere a cmo usamos la computadora de la organizacin). Procedimientos Documentados: un procedimiento es un camino especfico para realizar alguna tarea o actividad. En general se descompone en una serie de pasos, a cada uno de los cuales se les asigna un responsable, las tareas que debe realizar, y (de ser necesario) dnde queda un rastro o evidencia de que las tareas se realizaron. ste es un documento importante para mantener la repetibilidad de los controles administrativos ya mencionada. Instructivos de Trabajo: son instrucciones detalladas y muy dependientes del contexto sobre cmo realizar una funcin o tarea especfica (con un alto contenido de cmo). Se diferencian de los procedimientos en que el instructivo no asigna responsabilidades (slo se explica cmo se debe desarrollar una tarea, independientemente de quin lo haga). Guas: son documentos que establecen recomendaciones o sugerencias, pero no de cumplimiento obligatorio. Una gua puede servir como referencia metodolgica o para interpretar una situacin particular. Por ejemplo, la norma ISO/IEC 27002 (la ex ISO/IEC 17799) es una gua para la implementacin de controles de seguridad, y se la toma como referencia normativa para la correcta interpretacin de la norma ISO/IEC 27001 (que s es de cumplimiento obligatorio, pero no siempre es sencilla de aplicar a todas las circunstancias). Registros: son aquellos documentos en donde se guardan resultados obtenidos o evidencia de actividades desempeadas. Por lo general los registros cuentan con una plantilla (o template) que se van completando en forma manual o automtica. Por ejemplo, un log de accesos de un servidor, una base de datos donde se guardan los datos de un sistema CRM, un formulario, una orden de pedido impresa y archivada, etc. En Seguridad de la Informacin, los registros son muy importantes (lo mismo que asegurar que no sean manipulados) para mantener el registro de responsabilidad (o accountability).
Adems de los distintos tipos de documentos que una organizacin requiere, un esquema documental debe contar con un proceso asociado que controle la redaccin, la posterior revisin (por ejemplo, por el rea de Seguridad, Legales o Auditora para asegurar el cumplimiento de ciertos requisitos indispensables), la publicacin y la distribucin, as como el aseguramiento de que los documentos se encuentran disponibles y que no se usan versiones obsoletas25. Conviene definir las actividades y responsabilidades de control de la documentacin en un procedimiento operativo (o equivalentemente, un control administrativo) que asegure el resguardo de la informacin documental. Se trata de un control doble: por un lado se protege la propia informacin documentada, pero tambin (de manera indirecta, si se quiere) los dems activos de la organizacin protegidos por controles que se apoyan en dicha documentacin.
25
Nuevamente, estos requisitos estn alineados con cualquier estndar ISO.
36
2.11 Gestin de Incidentes

Existe todo un conjunto de controles detectivos que se pueden implementar para descubrir eventos e incidentes de seguridad. Un evento de seguridad es cualquier ocurrencia que indique la posibilidad de que se haya violado la poltica de seguridad, haya fallado algn control o situacin previamente desconocida que pueda ser relevante desde la seguridad; un incidente de seguridad es uno o varios eventos de seguridad, inesperados o no deseados que tienen una probabilidad cierta y significante de comprometer la operacin del negocio o amenazar la seguridad de la informacin. La organizacin debe ser capaz de detectar la mayor cantidad de incidentes para poder responder en tiempo y forma. Debe existir un proceso de escalamiento de los incidentes, comprendido por personas clave de la organizacin (no solamente los administradores de seguridad), contencin y recupero de los mismos. Otro aspecto importante de la gestin de la Seguridad de la Informacin tiene que ver con la retroalimentacin generada a partir de la informacin de la que disponemos para saber si las acciones tomadas han sido eficaces o no. Las buenas prcticas establecen que los incidentes tambin nos deben dejar lecciones aprendidas. El control detectivo (y administrativo) ms obvio para obtener esta retroalimentacin es la revisin de los logs de los distintos sistemas y dispositivos de seguridad, servidores y estaciones de trabajo. No es una tarea fcil de gestionar en forma consistente y es muy demandante de tiempo y de habilidades tcnicas. En la prctica, la abundante cantidad de datos generados en los sistemas reviste una dificultad fundamental, ya que se supone que una persona lo suficientemente preparada los debe revisar de manera rutinaria, dedicando una buena cantidad de su tiempo con el objetivo de descubrir algn hecho extrao que merezca su atencin. El triste resultado es que en la mayora de los casos ser una falsa alarma, o no habr suficiente informacin como para realizar un diagnstico preciso de lo que realmente ocurri. Existe un problema motivacional evidente, por un lado, se necesita un profesional altamente preparado para poder separar la paja del trigo, pero que realice una tarea muy rutinaria, ms tpica de una posicin ms bien inicial o junior. Y, dando vuelta el razonamiento, una persona que acaba de iniciarse y que probablemente aprecie tener que deglutir en forma rutinaria una buena cantidad de datos como parte de su incipiente formacin profesional, no estar lo suficientemente capacitado ni enterado de los detalles operativos y de infraestructura requeridos para el anlisis. An con la implementacin de poderosas herramientas informticas de anlisis y correlacin de eventos, que nos prometen automatizar al mximo lo rutinario y aburrido para un humano, consolidando la informacin necesaria para que un experto la analice, el problema sigue siendo difcil de abordar. Por un lado, las herramientas requieren de un perodo de varios meses de ajuste o
37
tunning26, para poder filtrar informacin redundante o no deseada (tpicamente, falsas alarmas). Este ajuste es importante, no slo para evitar insensibilizar a quien realiza el anlisis (despus de un perodo de acostumbramiento a falsas alarmas, uno tiende a menospreciar situaciones que realmente podran ser riesgosas), sino tambin para optimizar los recursos requeridos para el almacenamiento de los datos. Existe otro problema relacionado con las fuentes de donde se obtienen los eventos que estamos analizando. El grado de compatibilidad de la herramienta de anlisis con los equipos desde donde los eventos son detectados no siempre es la ptima, y adems, nuevas fuentes pueden aparecer o desaparecer en forma dinmica, en funcin a las necesidades operativas de la organizacin. Para volver ms difcil esta situacin, las fuentes en muchos casos son administradas por diversas reas de la organizacin. Por ejemplo, si el Departamento de Tecnologa necesita aliviar la carga de la infraestructura de la que es responsable, no va a estar deseoso de esperar a que el Departamento de Seguridad tenga lista la aplicacin de captura de incidentes antes de poner en produccin un nuevo servidor. El tema central en la gestin del anlisis y correlacin de eventos es entender que no se trata de un proyecto de seguridad, sino de una actividad que involucra a toda la organizacin. Como tal, previamente a la implementacin de una herramienta tecnolgica debe existir un procedimiento de escalamiento de cualquier sector operativo al detectar un evento o incidente de seguridad. Nuevamente, se trata de un control administrativo, y para que tenga xito, se requiere de coordinacin y entrenamiento entre los dems sectores operativos involucrados (y en el propio sector de Seguridad), no slo en cuanto a lo tcnico (por ejemplo, definir qu constituye concretamente un evento o incidente), sino tambin frente a la importancia de la deteccin de eventos para la gestin de la Seguridad (toma de conciencia).
2.12 Gestin de la Continuidad del Negocio

Se podra escribir un libro completo slo sobre Gestin de la Continuidad del Negocio o BCM (por Business Continuity Management). De hecho, existe una gran cantidad de libros sobre la materia, que adems cobr relevancia despus de los atentados a las torres gemelas y desastres tales como los producidos por el Huracn Katrina en EE.UU. Se trata de uno de los temas con mayor nivel de madurez dentro de la Seguridad de la Informacin, y es el que ms fcilmente entiende y apoya la Alta Direccin. Desde la perspectiva de la Seguridad de la Informacin, la propiedad de la informacin que se protege es la disponibilidad, pero sobre todo (y por eso el apoyo antes mencionado) se protege la continuidad de las funciones del negocio, incluso durante una situacin de emergencia, o luego de un desastre.
26
O tuneo, como se dice en la jerga tecnolgica.
38
La Continuidad del Negocio se puede definir de la siguiente manera: cmo mantener el negocio de la organizacin funcionando, todo el tiempo, a pesar de las contingencias externas. Pero vale la pena introducir la definicin de la norma britnica BS 25999-1 (Cdigo de Prctica de Gestin de la Continuidad del Negocio), que no es ni ms ni menos que una recopilacin bastante reciente (de 2006) de las buenas prcticas en Continuidad del Negocio: 2.3 Gestin de la Continuidad del Negocio Proceso integral que identifica amenazas potenciales a la organizacin y los impactos a las operaciones del negocio que esas amenazas, podran causar si se concretan; y que provee un marco de trabajo para la construccin de resiliencia organizacional mediante la capacidad para una efectiva respuesta que proteja los intereses de las partes interesadas, la reputacin, la marca y las actividades que agregan valor. Nota: la gestin de la continuidad del negocio incluye la gestin del recupero o continuidad de las actividades del negocio en caso de una interrupcin, y la gestin del programa general a travs de entrenamientos, ejercicios y revisiones, para asegurar que los planes de continuidad del negocio se mantienen actualizados.27 Dicho de otra manera, la Gestin de la Continuidad del Negocio es un proceso continuo de preparacin para cuando ocurra un incidente (ms o menos grave) que pueda interrumpir el normal desenvolvimiento de las actividades de la organizacin. El proceso continuo de gestin y gobernabilidad apoyado por la Alta Direccin y con los recursos apropiados se llama Programa de Gestin de la Continuidad del Negocio, y cuenta con las siguientes etapas, segn la norma BS 25999-1: Establecer la Poltica de BCM Asignar responsabilidades Definir, documentar, implementar y mantener las actividades del Ciclo de Vida de BCM Entender la organizacin Determinar la estrategia de BCM Desarrollar e implementar la respuesta de BCM Pruebas, mantenimiento y revisin Concientizar y entrenar a los involucrados
Una representacin bastante simplificada de lo que ocurre normalmente se muestra en la figura 2.11. Podemos considerar que desde el punto de vista del BCM, la organizacin se encuentra siempre dentro de dos estados: el estado normal, o el estado de emergencia. En estado normal, se desarrollan las actividades de gestin, prueba y mejora del esfuerzo de continuidad, que se
27
BS 25999-1:2006 Business continuity management Part 1: Code of practice, Londres, BSI, 2006, pg. 1.
39
documenta (principalmente) en los Planes de Continuidad del Negocio, o BCP por Business Continuity Plan(s). El o los BCP son una coleccin documentada de procedimientos e informacin que se desarrolla, compila y mantiene para su uso inmediato en un incidente, para que la organizacin contine con sus actividades crticas en un nivel aceptable predefinido28. Son las instrucciones que debe seguir la organizacin durante una emergencia.
estado normal
declaracin de la emergencia e invocacin del BCP
vuelta a la normalidad
estado de emergencia
Figura 2.11 A esta altura, resultan evidentes las similitudes de las buenas prcticas de Continuidad del Negocio con las de Seguridad de la Informacin: debemos establecer una poltica, asignar responsabilidades, documentar, determinar estrategias, implementar medidas, probar y revisar lo implementado y concientizar a los involucrados. Tampoco queda afuera la Gestin de Riesgos, slo que BCM se concentra ms en la identificacin de las consecuencias o impacto de las interrupciones del negocio (dicho proceso se llama Anlisis de Impacto en el Negocio o BIA, por Business Impact Analysis) que en la identificacin y ponderacin de las amenazas que provocan dichas interrupciones. Sin embargo, el proceso de Anlisis de Riesgos bien puede superponerse o complementarse con el de Anlisis de Impacto en el Negocio. El proceso de gestin de la Seguridad de la Informacin es tan similar al BCM que muchas veces, para contar con el apoyo de la Alta Direccin y de sectores claves de la organizacin, es preferible comenzar por un programa de BCM que incorpore gradualmente aspectos de Seguridad, antes que hacerlo con un Programa de Seguridad de la Informacin que contenga las actividades de BCM.
2.13 Cumplimiento (Compliance)

El trmino compliance muchas veces es utilizado como cumplimiento legal o regulatorio, pero en realidad, debe entenderse como cumplimiento de los requisitos. Dichos requisitos son externos a la organizacin: regulatorios,
28
Adicionalmente pueden existir Planes de Gestin de Incidentes (qu hacer inmediatamente ocurrido un incidente), y Planes de Recupero del Negocio (cmo volver a la normalidad una vez manejada la crisis), pero en general se los incorpora dentro de los BCP.
40
contractuales y legales, pero tambin de las buenas prcticas o requisitos implcitos derivados de las expectativas de los clientes y otras partes interesadas. Las actividades de cumplimiento estn empezando ser ms visibles en las organizaciones, sobre todo en la medida en que las leyes y gobiernos estn empezando a tomar nota de la importancia de la informacin para el funcionamiento de las sociedades. Los requisitos pueden analizarse de manera independiente y simplemente cumplirse. O pueden incluirse en el contexto de la gestin de los riesgos del negocio y analizarse como una amenaza ms (la de no cumplir con una reglamentacin, que supondr un impacto determinado). El enfoque utilizado depender del contexto de la organizacin (especialmente, el regulatorio). A medida en que las consecuencias de no cumplir los requisitos externos (de todo tipo: penales, econmicas, comerciales, o en imagen) cobran relevancia, aumenta la necesidad no slo de gestionarlos y cumplirlos, sino de evidenciar su cumplimiento. Muchas veces, la carga de la prueba est del lado de la organizacin, ya sea de forma explcita, o implcitamente debido a las expectativas generadas en las partes interesadas. Para requisitos bien definidos como los legales o regulatorios, evidenciar el cumplimiento puede ser ms o menos sencillo, en funcin de la calidad de la prosa de las leyes y contratos. Pero para el caso de otros requisitos ms ambiguos, como los relacionados con expectativas de seguridad (o privacidad) entran en juego dos conceptos muy utilizados en los pases ms adelantados en materia de cumplimiento (EE.UU y los pases de Europa): Due Dilligence (debido proceso): es el proceso de investigacin previo antes de tomar alguna decisin organizativa importante (adquisiciones, fusiones, venta, incorporacin de personal jerrquico, etc.) que da como resultado que la organizacin entiende los riesgos asociados con lo que se pretende hacer. Due Care (debido cuidado): es el principio del hombre razonable, muy utilizado en las cortes de EE.UU., que establece que la empresa hace (o hizo, en el caso de una disputa) todo lo que est (o estuvo) a su alcance para controlar los riesgos. El concepto del due care es independiente del resultado de un incidente de seguridad, slo se la considera culpable a la organizacin en la medida en que haya existido desidia en el debido cuidado.
En Argentina las normas ms comunes que motivan a las organizaciones a implementar programas de cumplimiento son: Sarbanes Oxley Act (SOX): ley de EE.UU. que regula a las organizaciones que operan en la bolsa de Nueva York, quienes deben demostrar eficacia en los controles vinculados a procesos que impacten sobre los estados financieros. Fortalece al gobierno corporativo e intenta reestablecer la confianza del inversor luego de los escndalos de Enron y WorldCom.
41
Payment Card Industry Data Security Standard (PCI): Estndar de Seguridad que deben cumplir las organizaciones que operan con VISA, Amex, MasterCard, Diners Club, JCB y Discover en materia de proteccin de datos de los consumidores para evitar fraudes con tarjetas de crdito. Ley Nacional de Proteccin de Datos Personales: ley Argentina de proteccin de informacin personal contenida en bases de datos de organizaciones. Las organizaciones deben registrar las bases de datos que contienen informacin personal y aplicar controles adecuados de proteccin. Se reglamenta con resoluciones de la Direccin Nacional de Proteccin de Datos Personales. Comunicacin A 4609 del BCRA: para entidades financieras (principalemente, bancos). Normativa basada en COBIT, las normas IRAM/ISO/IEC 17799:2002 e ISO/IEC 27001:2005, entre otras. Es el primer paso dentro del roadmap al cumplimiento de Basilea II.
2.14 Otros aspectos: tecnologa, personas y seguridad fsica

A lo largo del captulo se fueron recorriendo elementos claves de una buena gestin de la Seguridad de la Informacin. El esfuerzo requerido por todos los integrantes de la organizacin es considerable. Primero, se debe alinear el programa de seguridad con el negocio de la organizacin para que ste no carezca de realismo. Luego, deben plantearse directrices, planes y objetivos a cumplir, contando con la voluntad de invertir los recursos necesarios, ya sea en tiempo, dinero o en la asignacin de prioridades. Slo una vez que se cumplen estos requisitos (que las normas ISO llaman Responsabilidad de la Direccin) la implementacin del programa de seguridad puede avanzar sobre los aspectos ms bien administrativos que hemos cubierto a lo largo del libro: identificacin y clasificacin de activos de informacin, asignacin de dueos y custodios, gestin de los riesgos a la informacin, definicin de controles (o contramedidas), asignacin de responsabilidades, documentacin de actividades y controles, gestin de los incidentes (incluyendo la incorporacin de lecciones aprendidas), gestin de la continuidad del negocio y cumplimiento. Paralelamente, el programa de seguridad deber asegurar que las personas (el eslabn ms dbil de la seguridad segn numerosa bibliografa) estn adecuadamente entrenadas y enteradas de la importancia de la preservacin de las Seguridad de la Informacin en las actividades del negocio, tambin denominado toma de conciencia o awareness. Este aspecto se trata con ms detalle en el episodio 2. Por ltimo, las buenas prcticas reconocen la importancia de la Seguridad Fsica y Ambiental para la proteccin de la informacin y las personas que la generan y toman decisiones basadas en ella. La Seguridad Fsica, Ambiental y Patrimonial es ms antigua como disciplina que la Seguridad de la Informacin y su bibliografa tanto o ms extensa. Los conceptos y
42
recomendaciones son, en muchos casos, asimilables y anlogos en ambas disciplinas, al punto tal que en ambas industrias se est empezando a hablar de una convergencia de las dos disciplinas. Por un lado, la seguridad fsica de los equipos (incluyendo cableado, servicios de soporte, etc.) y las condiciones del medio ambiente (humedad, contaminacin, temperatura, etc.), influyen de manera directa en la preservacin de la informacin; y por el otro, la tecnologa de la seguridad patrimonial, ambiental o fsica, depende cada vez ms de otros sistemas con informacin de soporte que debe ser protegida (pensemos, por ejemplo, en la importancia de los perfiles de acceso en un sistema de control de puertas y molinetes con tarjetas de aproximacin). Es en este punto de la implementacin del programa de seguridad, despus de considerar todos los aspectos organizacionales antes mencionados, que podemos pensar en aplicar eficazmente la tecnologa de seguridad en la forma de: productos, software, hardware, sistemas, appliances, tokens, passwords, encripcin, controles de acceso, firewalls, antivirus, cintas de backup, parches de seguridad, entre otros. Existe todo un universo de tcnicas y conocimientos especficos que aplican a este campo que las buenas prcticas normalmente llaman: seguridad operacional; controles de accesos; seguridad en el desarrollo de software; seguridad en aplicaciones (incluyendo seguridad web y seguridad de bases de datos); criptografa; diseo y arquitectura de seguridad (en software de base, hardware y componentes electrnicos); y seguridad en redes, entre otros. Este aspecto tecnolgico excede el alcance del libro por su complejidad, longitud y constante cambio. No es por considerar que la tecnologa es poco importante que la ubico a continuacin de una serie de requisitos organizacionales, sino todo lo contrario: la tecnologa es la causa por la que nos estamos convirtiendo en sociedades de la informacin (y en definitiva, lo que motiva este libro). Pero las recomendaciones que surgen de las buenas prcticas de seguridad, que en principio deberan disminuir la complejidad de su gestin. No son fciles de llevar de la teora a la accin, y es esta dificultad la que explica la mayora de los fracasos en la preservacin de la confidencialidad, la integridad y la disponibilidad de la informacin, que sustenta tanto el negocio de una organizacin, como su razn de ser. En los prximos episodios de esta serie, intento dar cuenta de los aspectos prcticos y de su complejidad, as como tambin de una solucin integradora, implementando un Sistema de Gestin de Seguridad de la Informacin (SGSI) alineado con los requisitos de la norma ISO 27001.
43
A Anexos
A.1 Bibliografa utilizada
Buenas Prcticas de Seguridad de la Informacin: Harris, Shon: CISSP Certification, All-In-One Exam Guide, Second Edition, Emeriville, McGraw-Hill, 2003. Information Systems Audit and Control Association (ISACA), htttp://www.isaca.org. Jaquith, Andrew: Security Metrics: Replacing fear, uncertainty, and doubt, Upper Saddle River (NJ), Addison-Wesley, 2007. Mitnick, Kevin y Simon, William: The Art of Deception: Controlling the Human Element of Security, Indianapolis, Wiley Publishing, 2002. Mitnick, Kevin y Simon, William: The Art of Intrusion: The Real Stories Behind the Exploits of Hackers, Intruders & Deceivers, Indianapolis, Wiley Publishing, 2005. National Institute of Standards and Technology (NIST), http://www.nist.gov. Schneier, Bruce: Secrets and Lies: Digital Security in a Networked World, Nueva York, John Wiley & Sons, 2000. Tipton, Harold y Henry, Kevin: Official (ISC)2 Guide to the CISSP CBK, Boca Ratn, Auerbach, 2007.
Normas ISO y BS: BS 7799-3:2007 Information security management systems Part 3: Guidelines for information security risk management, Londres, BSI, 2006. BS 25999-1:2006 Business continuity management Part 1: Code of practice, Londres, BSI, 2006. BS 25999-2:2007 Business continuity management Part 2: specification, Londres, BSI, 2007. IRAM ISO 9001:2000 - Sistemas de Gestin de la Calidad - Requisitos, Buenos Aires, IRAM, 2001. ISO 9000:2005 - Sistemas de Gestin de la Calidad - Fundamentos y Vocabulario, Suiza, ISO, 2005 (traduccin certificada). ISO/IEC 27001:2005 Information technology Security techniques Information security management systems Requirements, Suiza, ISO, 2005. ISO/IEC 27002:2005 Information technology Security Techniques Code of practice for information security management, Suiza, ISO, 2005.
Buenas Prcticas de Gestin (Management) y Tecnologa de la Informacin: Adams, Scott: The Dilbert principle, Nueva York, Harper Collins, 1997. Dilbert.com, http://www.dilbert.com. Drucker, Peter: Management, tasks, responsibilities. practices, Nueva York, Harper Perennial, 1993
44
Gros, Carlos Augusto: Gestin de Riesgos, Buenos Aires, Intercoop, 2006. Mintzberg, Henry: Mintzberg y la Direccin, Madrid, Ediciones Daz de Santos, 1991. Saroka, Ral Horacio: Sistemas de informacin en la era digital, Buenos Aires, Fundacin OSDE, 2002.
A.2 Acerca del Autor

Juan Ignacio Trentalance es Ingeniero Electrnico por la Universidad de Buenos Aires (UBA), recibido con Diploma de Honor, y Especialista en Gestin de Servicios de Tecnologa y Telecomunicaciones por la Universidad de San Andrs (UdeSA). El presente libro est basado en la tesina requerida para completar la especializacin. Es Director de Porto, Trentalance, Antnez y Asociados, consultora que se dedica a la Seguridad de la Informacin y a la Calidad, con foco en la implementacin de Sistemas de Gestin basados en las normas ISO (9001, 27001, 20000, etc.). Es CISSP (Certified Information Systems Security Professional) por ISC2 (International Information Systems Security Certification Consortium), Auditor Lder en ISO 9001 e ISO/IEC 27001 por Det Norske Veritas (DNV), y Evaluador de Calidad en Auditoras Internas por el Instituto de Auditores Internos de la Argentina (IAIA). Tambin es egresado del Programa de Formacin de Emprendedores en el Centro de Emprendedores del Instituto Tecnolgico de Buenos Aires (ITBA). Tiene experiencia como Analista de Seguridad Informtica y en assessments de Seguridad de plataformas Unix, redes de datos y de telecomunicaciones. Se ha desempeado como coordinador de Seguridad Operativa en Movistar y como consultor independiente para empresas de primer nivel. Particip como implementador en uno de los primeros Sistemas de Gestin de Seguridad de la Informacin (ISMS) de la Argentina en la empresa Interbanking, certificado por TV Rheinland bajo la norma ISO/IEC 27001. Es docente de la Especializacin en Servicios y Redes de Telecomunicaciones de la Facultad de Ingeniera de la UBA, en la materia Seguridad en Redes de Telecomunicaciones. Adems ha participado como instructor en cursos intensivos de preparacin para la certificacin CISSP, y ha dictado seminarios y conferencias sobre Biometra, Business Impact Analysis, Seguridad Operativa, ISO 27001 y Mtricas de Seguridad. Ha realizado investigaciones en tecnologa de Biometra por Voz en la UBA con el apoyo del Gobierno de la Ciudad de Buenos Aires. Es miembro de ISSA (Information Systems Security Association), y socio fundador y actual Presidente del captulo local ISSAArBA (ISSA Argentina Buenos Aires). Participa del Comit Acadmico Segurinfo de la asociacin USUARIA.
45

Seguridad y Riesgo

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Seguridad y Riesgo

Uploaded by

Copyright:

Available Formats

Manual de supervivencia de Seguridad de la Informacin

Episodio 1: Lo que todo iniciado debe conocer

Juan Ignacio Trentalance

Manual de supervivencia de Seguridad de la Informacin Episodio 1

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

1 Por qu este libro

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

2 La gestin de la Seguridad de la Informacin

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

2.1 Por qu protegemos la informacin: datos, informacin y sistemas

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

2.2 Qu significa proteger la informacin

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

2.3 Las buenas prcticas en Seguridad de la Informacin

Manual de supervivencia de Seguridad de la Informacin Episodio 1

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

Activos Procesos Personas

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

2.4 Alta Direccin y Poltica Corporativa de Seguridad

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

2.5 Activos a proteger

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

2.6 Clasificacin de la Informacin

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

2.7 Gestin de Riesgos

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

Controles y Contramedidas de Seguridad Activos

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

Valor del Activo Bajo Medio Alto

Alto Bajo 3 4 5 Medio 4 5 6 Alto 5 6 7

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1

Riesgo Amenaza1 2x10=20

Riesgo Amenaza2 8x6=48

(c) Juan Ignacio Trentalance, 2010.

Manual de supervivencia de Seguridad de la Informacin Episodio 1