31 octubre 2007

Seguridad o Gestión de la Seguridad?

Con la creciente popularidad de las normas ISO de la familia 27000 y el auge que está cobrando la gestión de la seguridad de la información en muchos ámbitos, parece como si se hubiera desatado una obsesión general por gestionar la seguridad. El problema es que en muchos casos se está empezando a confundir la gestión con la seguridad, y en algunos incluso olvidándose esta última.

La gestión de la seguridad es, en principio, el nivel más avanzado en relación a la seguridad. Pero para llegar a este nivel es obviamente necesario haber superado los anteriores. Para gestionar la seguridad antes debemos tener seguridad. Parece una obviedad, pero la realidad es que no siempre se tiene en cuenta. No debemos tener en cuenta que el objetivo no es la gestión, sino la seguridad, y que la gestión es sencillamente una vía para mantener y mejorar sistemáticamente la seguridad. Es la vía más avanzada, y para llegar a ella tendremos que haber superado las anteriores. Si no, el batacazo será estrepitoso, y tarde o temprano llegará.

Vamos a por un ejemplo, que probablemente sea la forma más sencilla de verlo: Un antivirus. Qué pretendemos conseguir con él? Estar libres de virus, para no sufrir los efectos dañinos que pueden ocasionar si nos infectamos. Querríamos detectar y eliminar todos los virus que lleguen a nuestro PC. Dónde está la seguridad y dónde la gestión de la seguridad en relación a este antivirus?

Imaginemos una empresa que tiene un parque de PCs en el que todos los equipos tienen su antivirus totalmente actualizado, con un motor de detección que combina heurística avanzada y nuevas firmas que se publican diariamente, que detecta todo tipo de malware, que escanea automáticamente todo el parque de PCs, ... Tenemos el mejor antivirus posible, y con la mejor instalación y configuración posible. Eso es seguridad. Independientemente de que la configuración esté o no documentada, de que se revise periódicamente o de que monitoricemos la tasa de actualización de los antivirus.

Ahora pensemos en otra empresa con un antivirus del montón, sin heurística, de un fabricante que publica nuevas firmas de vez en cuando, que sólo está instalado en los PCs más nuevos de la empresa, ... Tenemos un antivirus mediocre con una instalación y configuración mediocre. Tenemos seguridad? No mucha. Sin embargo, esta empresa tiene totalmente documentada su política de antivirus, la dirección la revisa anualmente, tiene indicadores que le permiten conocer el % de ordenadores con el antivirus actualizado, mide como incidentes de seguridad todas las infecciones detectadas y no eliminadas, ... Tiene una muy buena gestión de la seguridad en relación al antivirus. Se ve la diferencia?

Evidentemente, he simplificado mucho las cosas. En el primer caso la seguridad de la empresa en relación a los virus es muy buena... en ese momento. Si no hay una gestión asociada, ese nivel de seguridad no se podrá mantener. Habrá que hacer un seguimiento de la situación si queremos seguir garantizando ese nivel de seguridad. Y en el segundo caso, si la gestión de la seguridad es muy buena, habrá seguimiento del estado, revisiones periódicas y auditorías que nos digan que nuestra protección frente a virus no es muy buena, y se establecerán medidas correctoras para solucionar estas carencias, de forma que a medio plazo probablemente se podría alcanzar una situación aceptable. Las cosas nunca son blancas o negras, y en este caso tampoco iba a ser menos. Sin embargo, creo que el ejemplo ha servido para aclarar las diferencias.

Esta dicotomía no tiene por qué ser grave, ya que es muy habitual que ambas tendencias, mejor o peor llevadas, tiendan a converger. Esa es su evolución natural. El problema puede surgir cuando se introducen factores que pueden hacer que cambie el rumbo de esa convergencia natural. Y uno de esos factores puede ser la certificación de sistemas de gestión. Si la obtención de un certificado que avala un sistema de gestión se considera algo positivo, puede que la empresa centre sus esfuerzos en la gestión, y tienda a olvidarse de la seguridad. Incluso puede llegar a romper esa convergencia natural, y primar la gestión sobre la seguridad. No es algo nuevo, esto ya ha ocurrido en muchos casos en relación a los sistemas de gestión de la calidad (recordais?). Y creo que este es el momento de empezar a recordar estos peligros, antes de que la seguridad corra el peligro de convertirse en la secuela de la "decepción de la calidad". Todavía estamos a tiempo de paranos a pensar, y una reflexión a tiempo siempre sirve de ayuda...

24 octubre 2007

El lunes Javier Cao publicó este interesante post acerca de la preocupante situación general en materia de seguridad de la información en España. En él comenta los indicadores que utiliza el INTECO para medir el estado de la seguridad informática en los hogares españoles, y en particular analiza y comenta los indicadores referentes a los motivos que alegan los ciudadanos para no poner en práctica ciertas medidas de seguridad y a la percepción general de la seguridad por parte de la ciudadanía.

Sin entrar a valorar específicamente los indicadores, sí que me gustaría aportar mi punto de vista sobre sus posibles causas y algunas posibles vías de actuación. Porque con lo que sí coincido completamente es con la visión pesimista que ofrecen los citados indicadores.

El principal problema, creo yo, es que no hay conciencia social en relación a la seguridad. Pero no sólo porque a la gente no le preocupe la seguridad, sino porque la desconocen. En muchos casos, los ordenadores son unos cacharros con los que te peleas hasta que consigues hacer lo que quieres, más o menos, y a su manera. En otros, son un juguete más o menos sofisticado con el que enredar. Y en otros, símplemente una vía para acceder a un montón de material gratuito que realmente sólo interesa por el hecho de que no hay que pagar específicamente por él. En resumen, una herramienta bastante compleja cuyo funcionamiento real se desconoce y no interesa, mientras haga lo que nosotros queremos.

Creo que el principal problema está en convencer a los usuarios de que los ordenadores no hacen sólo lo que queremos, que aunque no se den cuenta están realizando un montón de tareas además de las que ellos les encomiendan. Y que si no los entiendes bien, ni siquiera conseguirás que hagan lo que tú quieres, sino sólo algo que se le parece. Los usuarios deben ser conscientes de la complejidad real de la máquina que tienen entre manos. Porque sólo si lo vislumbran se empezarán a preocupar. Y sólo si se preocupan (perciben el riesgo) decidirán que puede ser interesante adoptar ciertas medidas de seguridad.

Por otra parte, creo que sería necesario realizar un esfuerzo para conseguir que el usuario medio doméstico conozca las distintas soluciones gratuitas de seguridad que existen. Hay muchas webs públicas donde se pueden localizar, pero... ¿Cuántas de estas webs son visitadas por el usuario doméstico medio?

También creo que sería necesario que estos productos (antivirus, antispyware, firewall personal, etc.) estuviesen integrados en los equipos desde el momento inicial (compra). Pero no una versión temporal, sino una completamente funcional y por la que el usuario no deba pagar. Seamos sinceros, la mayor parte de los usuarios no paga por seguir utilizando algo que le han "regalado" sin pedirlo expresamente. Y tampoco si lo puede conseguir sin pagar por una vía alternativa. Así el usuario adquiriría un producto en el que la suite de seguridad no provoca ralentizaciones adicionales (ya que no conoce la velocidad sin ella) y cuya estabilidad y funcionamiento adecuado de partida estaría probado.

En definitiva, creo que las vías de actuación pasan por "obligar" al usuario a disponer de soluciones de seguridad fácilmente utilizables, y por "meterle miedo" hasta que sea consciente de los riesgos que existen. No son soluciones políticamente correctas, pero a corto plazo me parecen más efectivas que un programa de concienciación colectiva acerca de la seguridad de la información. Y de hecho podrían servir de caldo de cultivo para que una posible campaña de concienciación tuviera más gancho. Al fin y al cabo, la inseguridad no es un enemigo que juegue limpio...

22 octubre 2007

Gestion de cambios

Uno de los aspectos fundamentales en la gestión de la seguridad (y de cualquier otra cosa) es la gestión de cambios. Todos nos sentimos relativamente cómodos gestionando aquello que no cambia, que es estático. Somos animales de costumbres. El problema es que los cambios son inevitables, y por tanto tenemos que ser capaces de afrontarlos. Una buena gestión de cambios es clave si queremos mantener nuestros niveles de seguridad a lo largo del tiempo...

En primer lugar, es importante identificar los cambios. Cambios que no tienen por qué ser internos o por iniciativa propia, sino que se pueden producir en el entorno. Y el punto crucial es ser capaces de detectarlos. Nuevas amenazas o vulnerabilidades quizás sean el ejemplo más socorrido, pero no tiene por qué ser el único. Cualquier factor del entorno, tanto cercano como lejano, puede cambiar, y nosotros tenemos que ser capaces de identificarlo y evaluarlo.

La segunda parte es, como acabo de indicar, evaluar el impacto de los cambios. Tanto directo como indirecto, tanto inmediato como a largo plazo. Ahora bien, hay que ser prácticos. No podemos evaluar absolutamente todas las consecuencias, muchas veces no sólo es poco rentable sino que es prácticamente imposible. No podemos estar evaluando infinitamente, la gestión de cambios debe seguir. Habrá que evaluar los pros y los contras más evidentes, sopesarlos, y decidir. Que habrá consecuencias que no hayamos previsto? Seguro. Y es que en cualquier decisión estamos asumiendo riesgos. Pero que conste que también lo hacemos si continuamos con nuestra evluación...

Decidir es el punto crítico. Hacer algo, o no hacer nada. Pero debemos tener en cuenta que la decisión de partida es no hacer nada. Mientras estamos evaluando, no estamos reaccionando al cambio. Estamos tomando, de facto, la decisión de no hacer nada. Y esa decisión tiene sus riesgos, al igual que la decisión de reaccionar al cambio. Sea cual sea la decisión, algo debe quedar patente: quién asume la decisión, sus motivos, y sus consecuencias. Y si estos tres factores quedan por escrito, mejor que mejor.

Hasta ahora hemos pensado que nuestra decisión de cambio es como reacción a otro cambio externo. En general suele ser así (reacciones a los cambios del entorno, del negocio, de las estrategias, ...), pero aun en caso de que el cambio sea originado internamente, la situación es idéntica: habrá que especificar quién decide (en base a sus funciones y responsabilidades), sus motivos, y las consecuencias previstas por dicha decisión.

Una vez que hemos recorrido el circuito de decisión del cambio, el resto es fácil. Hay que planificar (pensar) el cambio y cómo se va a llevar a cabo, ejecutarlo, verificarlo y registrarlo. El circuito típico. Sin embargo... cuántas veces se cumple por completo? Además, tenemos que tener en cuenta que dentro del ciclo de "ejecución" del cambio pueden aparecer nuevos factores que realimenten a la fase de decisión, y que puedan llegar a motivar su cambio. Esto no es algo que deba asustarnos, o que debamos evitar: una correcta gestión de cambios debe tenerlo en cuenta. Pero debe tenerlo en cuenta de esta forma, sin necesidad de una planificación "virtual" de todo el ciclo en la fase de decisión. Si no, nunca reaccionaremos a los cambios...

Quizás la mejor forma de ilustrar todo este ciclo es con un ejemplo. Pensemos en la publicación de una vulnerabilidad asociada a una aplicación de nuestro servidor central. El entorno ha cambiado. Cuál es la reacción asociada? Parchear. Qué inconvenientes tiene? Inestabilidad, mal funcionamiento, necesidad de una parada programada... Las ventajas también son claras: reducción del nivel de riesgo, que ha aumentado al publicarse la vulnerabilidad. Quién debe decidir? Supongamos que el director de sistemas, con el asesoramiento del responsable de seguridad y de los técnicos expertos en la aplicación y el servidor central. Qué decide?
Hasta este punto, la historia es más o menos sencilla. Pero... qué ocurre si el director de sistemas no cuenta con un entorno de pruebas para verificar la estabilidad del parche? O si el personal no tiene tiempo para realizar las pruebas? O si no cuenta con la asesoría necesaria? Sencillamente, que el riesgo de tomar la decisión aumenta. Pero esto en ningún caso significa que no pueda tomar la decisión. Y vuelvo a decir que mientras se llevan a cabo las pruebas, o se buscan recursos, se está tomando la decisión de no hacer nada, y por tanto asumir el riesgo asociado a la vulnerabilidad que se acaba de publicar.
Si el director de sistemas decide parchear, lo siguiente será planificar la parada, procedimentar el parcheo si es necesario, ejecutarlo, verificar la estabilidad del sistema tras la operación, registrar las tareas realizadas, ... Y que conste que todas estas fases son necesarias, no vale sólo con la ejecución. Por supuesto, "con cabeza": probablemente la instalación de una nueva fuente TrueTipe no requiera la misma profundidad de gestión que el parcheo de la base de datos Oracle. Aunque sí las mismas fases...

En resumen, una buena gestión de los cambios es clave para la seguridad. Tanto a nivel IT como a cualquier otro: documental, operativo, contractual, ... Nuestra gestión de cambios deberá ser integral, y asegurar que se cumplen todos los pasos en todos los entornos. Y si no, ser conscientes de que estamos asumiendo el riesgo de no realizar una correcta gestión de cambios. Cómo se cuantifica este riesgo? Eso ya es otra historia...

19 octubre 2007

Fallos de recuperación

Ayer estuve leyendo la noticia que publicaban en VNUnet acerca del estudio publicado por Symantec en relación a la continuidad de negocio. La verdad es que no aporta grandes novedades, pero creo que merece la pena hacer algunos comentarios al respecto.

En primer lugar, me llama la atención la afirmación de apertura del artículo. Y no tanto porque refleje las dificultades de gestión económica intrínsecas a la gestión de riesgos, sino porque hace referencia al "director de sistemas". Entiendo que es Symantec, y que por tanto hablan de IT, pero no puedo hacer otra cosa que recordar uno de los últimos post acerca de las diferencias entre continuidad IT y continuidad de negocio...

Las preocupaciones a nivel de seguridad tampoco son nuevas. Aparece el malware, los desastres (de origen natural o humano), las fugas de información y la no continuidad del negocio. La solución pasa, cómo no, por garantizar la disponibilidad de la información (con backups seguros), pero sin olvidar la seguridad (confidencialidad, integridad, control de acceso, etc.) de la misma.

La parte más llamativa viene de la mano de los datos numéricos. Se afirma que una empresa enfrentada a una situación de desastre muere en un año, sin un plan de recuperación. Dónde está el truco? Por supuesto, en que la probabilidad de que la empresa se enfrente a ese desastre es muy baja. Precisamente ese es el motivo de que muchas empresas carezcan de un Plan de Continuidad de Negocio. Y si los riesgos asociados a esta carencia están analizados y asumidos, la opción me parece totalmente lícita.

Por otro lado, tenemos la opción de implementar un Plan de Continuidad. Aunque si hacemos caso al informe, tampoco parece una opción muy halagüeña. Se consigue una sensación de seguridad, pero luego resulta que en el 50% de los casos el Plan falla. Y los motivos son muy amplios: plan mal diseñado, fallos en su ejecución o fallos en la tecnología. Pero... cuál es la causa última? Desde mi punto de vista, creo que el origen de estas situaciones es común: planes de recuperación implementados más "por cumplir" que por garantizar el negocio. Por eso no se prueban, y por eso fallan: falta concienciación.

En definitiva, creo que el problema es que la continuidad de negocio debe ser algo más que una moda entre la alta dirección. Deberá llegar el momento en el que se deje de pensar en quedar bien frente a los accionistas y se empiece a pensar en desarrollar Planes de Continuidad que realmente sean abordables, eficientes y eficaces. Porque sólo en ese momento la continuidad de negocio se podrá ver como algo de todos, y los departamentos de sistemas empezarán a tomárselo como una ventaja en lugar de entenderlo como un capricho impuesto. Porque en algunos casos, cierta razón no les falta...

15 octubre 2007

Cuanto le cobramos?

Este post es la respuesta a una invitación por parte de Antonio Valle a continuar un peculiar “meme”, sin reglas, acerca del precio de los servicios. Espinoso tema, eh? Sobre todo en el mundo de la consultoría. Pues precisamente esa es la reflexión que comenzó Tic616 aquí, siguió Antonio en este post, y ya veremos dónde acaba…

La verdad es que cobrar por horas suele ser una táctica habitual para los servicios de consultoría. A tanto la hora de consultor senior, a tanto la de junior… Como cuando vas a la charcutería a comprar embutido. Sin embargo, la diferencia entre un kilogramo de jamón cocido o una hora de consultor es evidente…

Es cierto que, como dicen en un famoso anuncio de televisión, hay cosas que no tiene precio… Y lo malo es que incluso a ésas alguien decide ponerles uno. Calculado, para más inri, con lápiz y calculadora y en un par de minutos (cuando no se usa la táctica de chuparse el dedo y levantarlo en alto como método empírico de cálculo). El resultado, por supuesto, suele ser poco agradecido tanto para el consultor, que ve cómo se subestima la importancia de su trabajo, como para el cliente, que acaba con la sensación de que le están tomando el pelo. Y algo de razón no le falta, cuando resulta que si el consultor es bueno y le resuelve la papeleta en la mitad de tiempo, a él le saldría a mitad de precio… Vamos, un sinsentido.

Para mí, esto del cobro por servicios se parece a una partida de mus. Hay unas empresas que juegan a grande, y otras que juegan a chica. Las que juegan a grande son esas empresas que apuestan por la formación, por la contratación de personal altamente cualificado… y que no pestañean al cobrarte una buena suma de dinero por resolver un determinado problema. Sin horas, sin cálculos para justificar el precio. Sólo teniendo en cuenta los resultados, y con la seguridad de que el cliente quedará satisfecho. Empresas capaces incluso de hablar de SLAs en este tipo de servicios. En definitiva, empresas que apuestan fuerte porque tienen varios reyes de mano. Cuántas hay de este tipo? No muchas, me temo.

El otro tipo de empresas son, como ya he dicho, las que juegan a chica. Las que tratan de ganar dinero hora a hora, punto a punto, envidando a chica cuando todos han querido el envite a grande. Es una estrategia contraria a la anterior, conservadora, que se queda con unas cartas mediocres si piensa que conseguirá algún punto. El objetivo es no perder dinero, así que se cobra por horas, tratando de garantizar en todo momento que se cubren los gastos y el margen para ese determinado servicio.

El problema en sí no es la estrategia de la empresa. Es tan defendible un caso como el otro. Cada uno tiene sus ventajas y sus inconvenientes. El peligro es, como en el mus, las empresas que juegan de farol. Que van de empresas punteras, que se venden como tales, pero que en realidad juegan sin cartas. Donde sus personas no están suficientemente formadas, ni se dan mus para buscar reyes que les permitan completar la mano. Estas empresas son un problema tanto para el mercado como para el cliente. Para este último, porque el riesgo de que sus expectativas no se vean satisfechas es alto. Y para el primero, porque demasiadas empresas de este tipo provocan una devaluación del mercado, y una sensación generalizada de que el sector de la consultoría vende humo. A alguien le suena?

En definitiva, esto del cobro por servicios es un tema que da para muchas reflexiones. Si sirven o no para llegar a alguna parte, ya se verá con el tiempo. Espero, al menos, que este semi off-topic haya sido ilustrativo… y que haya despertado el interés por el mus para todos aquellos que aún no lo conozcan. :-)

05 octubre 2007

BCMS o ITCMS?

La continuidad de negocio cada vez está más de moda. En este caso, el lanzamiento de la norma BS 25999-2 (requisitos para un BCMS) no hace más que reflejar el enorme interés de las organizaciones a nivel mundial en este tipo de soluciones.

Y pese a que esté tan de moda, en muchos casos es habitual encontrarse con graves errores de concepto en este ámbito. El más preocupante, a mi entender, es confundir un BCMS (Sistema de Gestión de la Continuidad del Negocio) con un ITCMS (Sistema de Gestión de la Continuidad de los Servicios IT). En demasiados casos se escucha el término continuidad de negocio para referirse a la continuidad de los servicios IT. Y las diferencias son enormes.

Es cierto que cada vez más las actividades de negocio están soportadas por la infraestructura IT. Sin embargo, negocio y servicios IT no tienen por qué ser lo mismo. De hecho, casi nunca lo son. Hay que aprender a diferenciar los servicios IT de los servicios profesionales, o prestados por personas. Por qué? Porque realmente hay muchos negocios que no son IT, sino profesionales. Y en esos casos, garantizando la continuidad de los servicios IT no garantizamos la del negocio.

Pensemos, por ejemplo, en la banca. Pueden funcionar las ventanillas sin ordenadores? Probablemente sí. Quizás no puedan hacerlo indefinidamente, pero para sacar o meter dinero en nuestra cuenta no necesitamos al ordenador, si la persona que está en la ventanilla puede registrar los movimientos a mano (y ya los volcará en los sistemas informáticos cuando estén disponibles).

En qué casos coinciden un ITCMS y un BCMS? En aquellos en los que el negocio es EN SÍ MISMO un servicio IT. Pensemos en la banca por Internet, o en las tiendas on-line. Esto no quita que en un ITCMS no haya que tener en cuenta a las personas, ya que los sistemas siempre son administrados y mantenidos por alguien, pero supone que un BCMS deberá exceder, y con mucho, al departamento IT. Si queremos que nuestro negocio de venta de tornillos siga adelante, nuestro BCMS tendrá que tener en cuenta aspectos como la línea de producción, la actividad de los comerciales, la logística... Si nos quedamos en un ITCMS para todos los sistemas, podemos encontrarnos con que una inundación o una nevada de esas que hacen historia nos paraliza por completo la actividad de nuestro negocio. Y si nuestros comerciales cogen una infección en una comida de empresa y se tiran en cama durante dos semanas, resulta que durante esas dos semanas no hay nuevas ventas. Eso sí: nuestros sistemas no han tenido ni un segundo de parada. Pero el negocio está parado...

En definitiva, creo que es necesario tener clara la diferencia entre negocio y servicios IT. Que cada día la dependencia es mayor, pero mientras el negocio recaiga sobre las personas, no será suficiente con salvaguardarnos ante una caida de la infraestructura informática. Y menos si resulta que las personas clave para el negocio están fuera del departamento IT...

03 octubre 2007

Gestion de terceros

Para seguir con la serie de recomendaciones de gestión de la seguridad, creo que es necesario hablar de la gestión de terceras partes. Quizás no tenga en todas las organizaciones la misma importancia, pero quien más quien menos debe trabajar conjuntamente con personas y organizaciones externas, y en estos casos necesitamos que estas terceras partes se comprometan a cumplir los mismos requisitos mínimos que cumplo yo (y si no, nuestra seguridad disminuirá, según el teorema de la cadena).

La primera necesidad es, sencillamente, regular el papel de estas terceras partes. Definir concretamente qué hacen y qué no, en relación a nosotros. Puede parecer una obviedad, pero este es el primero de los problemas. ¿Qué ocurre si hay una discrepancia? ¿Nos podemos agarrar al contrato? ¿A la oferta? Pero... ¿existe algún sitio en el que se especifique qué me suministra esta empresa, o qué horario de servicio tiene para mi? Es sorprendente la cantidad de veces que "no se encuentra" el dichoso documento...

Supongamos que ya tenemos claro el "catálogo de servicios recibidos". Ahora que ya conocemos el papel de estos terceros, podemos identificar en cuáles de mis actividades están implicados. Porque resulta que les tendré que exigir lo mismo que me exijo a mí mismo... en cada caso. Si el servicio soporta la fabricación, posiblemente no tenga sentido incluir exigencias de tratamiento de datos personales. Y a un servicio de limpieza no tiene por qué ser necesario exigirle una disponibilidad >99%. Los SLAs son necesarios en algunos casos, pero el sentido común es imprescindible en todos. Y no por meter más cláusulas y condiciones tenemos mejores contratos.

Pero resulta que la parte complicada en la gestión de terceros no es el contrato, que a fin de cuentas se redacta y firma una vez, sino su ejecución. Para una correcta gestión de terceros es necesario un seguimiento del mismo. Las reuniones periódicas entre la organización y los terceros son imprescindibles. Hay que hacer ajustes, aparecerán cambios que quieran introducir ambas partes, el mercado evoluciona... Además, los propios implicados en el servicio (por ambas partes) deben participar en este seguimiento. Jefes y comerciales suelen ser habituales en este tipo de reuniones, pero las fricciones surgen en el día a día, y los que las conocen son los que las sufren. Y por regla general también quienes más claramente pueden identificar fallos y posibilidades de mejora. Muchas veces basta con preguntar adecuadamente para obtener la respuesta que se busca...

Por último, y en términos de seguridad, es necesario prevenir la relajación. Seguro que el primer día, si estamos concienciados en materia de seguridad, establecimos todas las medidas necesarias para asegurar que las terceras partes cumplen con nuestras políticas. Comunicaciones seguras, logs de actividad, registros, ... Y cómo trabajamos hoy con nuestro proveedor, que ya es "de confianza"? Seguimos manteniendo las mismas medidas? La revisión y auditoría de este tipo de relaciones con terceras partes es una medida necesaria para prevenir la aparición de los problemas derivados de la relajación de las medidas de seguridad. Por supuesto que las medidas internas también deben ser auditadas de igual modo, ya que se suponen equivalentes, pero no podemos olvidarnos de los proveedores. Y os aseguro que pocas empresas proveedoras pasan auditorías de sus clientes.

En definitiva, la gestión de terceras partes es clave para garantizar la propia seguridad. Los SLAs, además de estar de moda, son una herramienta muy útil para regular esta gestión, pero no debemos olvidar que la parte complicada no es la firma del SLA, sino su cumplimiento. Y que una organización que sepa gestionar estas terceras partes, aunque no tenga ningún tipo de SLA, probablemente rinda a más nivel que una en la que se cumpla el caso contrario. Ah, se me olvidaba! Herramientas que se puedan utilizar en estos casos? Sobre todo, una sin automatizar y más cara de lo que parece: sentido común.