Modelos de "políticas" de seguridad

Vía ISO27002.es he podido dar con la Web
Open Directory - Computers: Security: Policy: Sample Policies que contiene un buen catálogo de documentos sobre políticas de seguridad.

En Guía para la elaboración del marco normativo de Seguridad ISO 27002 ya comenté las diferencias entre Política, Norma y Procedimiento aunque en ingles el término "policy" suele tener un carácter más general. Es habitual encontrar "policies" para todo, aunque muchas veces estos documentos tienen el objetivo de establecer regulaciones y por tanto deberían entenderse como normas.

Aumenta esta confusión además que en la norma ISO 27002 aparezca como control en el punto 5.1.1. la famosa "política de seguridad de la información".
En cualquier caso, el catálogo de documentación contiene una buena recopilación de diferentes enfoques a la hora de establecer un marco normativo, lo que suele venir bien cuando se anda intentando escribir estas cosas.

Como reflexión final, todo documento que intenta ser una política, norma o procedimiento tiene que tener un objetivo base "Que pueda ser algo cumplible".No se trata por tanto de hacer algo que quede bien o que sea completo, sino algo que sea real, asumible y cumplido por el área regulada.

La subcontratación del riesgo

Tenía pendiente desde hace unos días elaborar esta entrada. Tras unos comentarios en relación al post de Joseba Enjuto sobre la caracterización de los Servicios TI, quería hablar sobre la " subcontratación del riesgo". Lo primero que quiero justificar es el titulo. La gestión del riesgo sólo permite cuatro decisiones posibles:

• Aceptarlo
• Evitarlo
• Reducirlo o
• Transferirlo a un tercero

En general, se suele entender por transferencia del riesgo cuando éste se tiene identificado y se decide que un externo sea quien lo gestione a cambio de cierta contraprestación: habitualmente puede ser la externalización de servicios, la contratación de seguros, etc. Es habitual, como bien apuntaban en los comentarios de "Seguridad y Gestión" que el término para definir este proceso sea la "externalización del riesgo" pero ahora voy a justificar un poco por qué prefiero no llamarlo así. Yo concibo la idea de la externalización de un riesgo cuando una Organización identifica claramente qué necesita y establece una relación contractual de prestación de servicios que permite al cliente quedarse tranquilo respecto a cómo va a gestionar el tercero ese riesgo. Para ello, evidentemente, los servicios prestados por el tercero deberían poder acreditar ciertas garantías respecto a la seguridad con la que van a ser proporcionados. La existencia de unos adecuados "Acuerdos de nivel de servicio" ( o su término en ingles Service Level Agreement, SLA) centrados exclusivamente bajo la perspectiva de la seguridad podrían ser suficiente garantía. La Organización que traslada el riesgo sabe que en caso de problemas, podrá arremeter contractualmente contra la empresa a la que transfiere el riesgo siendo recompensada adecuadamente en caso de una gestión no adecuada de ese riesgo. Para ello, aparece el control 6.2.3 de la norma ISO 27002 que indica que "Los acuerdos que comporten el acceso de terceros a recursos de tratamiento de información de la Organización deben basarse en un contrato formal que tenga o se refiera a todos los requisitos de seguridad que cumplan las políticas y normas de seguridad de la Organización."

Si atendemos a la guía de implantación de la norma, que es la forma más completa de implantar el control, este tipo de ANS o SLA de seguridad deben cubrir cosas como:

• 1.-La política sobre seguridad de la información del tercero.
• 2.-Los controles para asegurar la protección de los activos que el tercero tiene implantado, incluyendo:
• procedimientos para proteger los activos de la organización, incluida la información, el software y el hardware.
• cualquier control o mecanismo de protección física requeridos.
• controles para asegurar la protección contra el software malicioso
• procedimientos para determinar si ha ocurrido algún incremento del riesgo de los activos, por ejemplo, pérdida o modificación de información, software o hardware;
• controles para asegurar la recuperación o destrucción de la información y los activos, al terminar el contrato o en algún momento acordado dentro del periodo de vigencia del contrato;
• la confidencialidad, integridad, disponibilidad, y cualquier otra propiedad importante de los activos
• restricciones en la copia o revelación de la información; junto con la utilización de acuerdos de confidencialidad
• 3.- Una clara estructura de los informes y de los formatos de informe acordados.
• 4.- Un proceso especificado y claro de la gestión del cambio.
• 5.- Disposiciones para informe, notificación e investigación de los incidentes de seguridad de la información e infracciones de seguridad, así como violaciones de los requisitos establecidos en el acuerdo.
• 6.- Una descripción del producto o servicio que se va a proporcionar, y una descripción de la información que se hará accesible, con su clasificación de seguridad.
• 7.- El nivel objetivo de servicio y los niveles de servicio inaceptables.
• 8.- La definición de los criterios de verificación del comportamiento, su control e informe.
• 9.- El derecho a controlar, y revocar, cualquier actividad relacionada con los activos de la organización.
• 10.- El derecho de auditar las responsabilidades definidas en el acuerdo, teniéndose que llevar a cabo tales auditorías por una tercera parte, y de enumerar las obligaciones y derechos legales de los auditores.
• 11.- El establecimiento de un procedimiento de escalado para la resolución de los problemas.
• 12.- Requisitos de continuidad de servicio, incluyendo las medidas de disponibilidad y fiabilidad, de acuerdo con las prioridades de negocio de la organización.
• 13.- Las responsabilidades respectivas de las partes del contrato.
• 14.- Las responsabilidades con respecto a temas legales y como se garantiza que se cumplen los requisitos legales, por ejemplo legislación de protección de datos, teniendo en cuenta sobre todo los distintos sistemas legales nacionales si el contrato implica la cooperación con organizaciones de otros países.
• 15.- Etc.

El primer problema con el que nos solemos encontrar en las Organizaciones es que se externalizan servicios pero no se definen, desde la perspectiva de la seguridad, en qué condiciones se transfiere el riesgo. Llegado a estas alturas del texto, cabe pensar si realmente conocéis a alguna empresa que "externalice su riesgo" o si en general todas "subcontratan servicios de riesgo" entendiendo por esto segundo, un término menos formalizado de dar a un tercero un riesgo. Quiero destacar que el riesgo SI se puede transferir, pero no así la responsabilidad. Por tanto, que las cosas no estén bien definidas, explícitamente documentadas y contractualmente reflejadas solo hace que perdamos "control" sobre nuestro riesgo que además, no vamos a gestionar nosotros mismos.

Dependerá de cómo entienda e interprete ese tercero el riesgo que asume al prestar el servicio el tipo de garantías que pudiera proporcionarnos en caso de un incidente de seguridad. Y lo que me parece más preocupante es que la "externalización de servicios TI" está muy de moda y si bien tenemos normas como ISO 20000 o ITIL que definen bien cómo debe hacerse este proceso y cómo deben establecerse los SLA y ANS, es importante que los aspectos relacionados con la seguridad queden perfectamente definidos. Es cierto que para los servicios TI el factor más importante a considerar suele ser la disponibilidad, pero debemos contemplar qué ocurriría si la naturaleza del incidente o error afecta a la integridad o confidencialidad de nuestra información.

Toda externalización supone pérdida de control si no se establecen mecanismos de regulación y seguimiento que permitan aportar evidencias, por parte del externo, de estar haciendo las cosas bien. A esta problemática general, todavía cabría añadir la complejidad que surge cuando se manejan cadenas de subcontratación. Si la empresa A transfiere un servicio a la empresa B, que a su vez utiliza a las subcontratas C y D para proporcionar el servicio final al cliente A. Si estos eslabones de subcontratación no están claramente identificados y bien atados, la empresa A puede ver comprometida su seguridad y no tener muy claro cuál ha podido ser la cadena de fallos y por tanto, la cadena de responsabilidades.

Y decía al principio que los acontecimientos siempre nos ponen de manifiesto estas reflexiones por el incidente este fin de semana en los hospitales madrileños. El titular de "El País" que se hace eco de la noticia es Siete hospitales se quedan seis horas sin sistema informático. Cuando hacemos el análisis de riesgos y estamos en la fase de valoración de activos, siempre usamos una escala denominada "laboral" donde precisamente se tiene en consideración si un incidente de seguridad puede costar "vidas humanas". Normalmente nuestros entrevistados suelen hacer alguna broma al respecto, pero es cierto que en ciertos "modelos de negocio", los servicios TI son críticos pudiendo causar la muerte de personas. Además, el proceso de digitalización que tantos beneficios genera y que tan bien venden nuestros políticos en relación a la atención sanitaria, tiene requisitos de seguridad que requieren hacer las cosas bien desde el principio. Sin entrar a valorar en concreto estos hechos, dado que no tenemos información suficiente que pudiera servir para valorar técnicamente que ha fallado, las evidencias son un cese de servicios de seis horas, algo posiblemente "intolerable" para un sector sanitario donde mucha información se requiere "en tiempo real". Merece la pena destacar frases como "La caída del programa la provocó una bajada de tensión eléctrica en la zona de Tres Cantos, donde está el centro tecnológico que aloja el servidor central de los nuevos hospitales". ¿Un sólo servidor para un activo de información tan crítico? ¿Ningún plan de contingencia para recuperarse frente a una situación así en menos de una hora? El blog APISCAM parece proporcionar más información sobre lo sucedido, aunque quizás con una versión menos imparcial (seguramente muy justificada). Parece que toda la gestión informática hospitalaria está subcontratada y en los diferentes pliegos y concursos se habían contemplado requisitos respecto a la continuidad de servicio.

De los hechos se deduce, al menos, un fallo grave en el plan de continuidad de negocio o planes parciales de contingencia. En sistemas de información como los del entorno hospitalario, con cada vez más dependencia de la tecnología para obtener información relativa al diagnóstico, hablamos de sistemas críticos que requieren información en tiempo real ("Fue el servicio de urgencias el que más sufrió las consecuencias de las demoras. "Tenemos que ir corriendo de un lado para otro para llevar historias, análisis...", explicaba ayer una enfermera de este departamento del hospital de Vallecas").

Quizás en el pliego las condiciones del servicio pudieran estar bien contempladas, pero para nada se ha garantizado la correcta supervisión de la ejecución del mismo y el adecuado cumplimiento del ACUERDO DE NIVEL DE SERVICIO. Además se suma que el supuesto Plan de Contingencias o de Continuidad de Negocio no ha funcionado, dado que la parada de seis horas es excesivo tiempo en el entorno hospitalario si se hubiera hecho el correspondiente BIA (Bussines Impact Analysis). Y por último y como reflexión final, quisiera destacar que el nuevo Reglamento de desarrollo de la Ley 15/1999 de Protección de Datos, ha incluido importantes y significativas reformas en torno a la figura del "encargado de tratamiento", que desde la perspectiva de la seguridad van en la línea de mejorar el control y la externalización del riesgo sobre los terceros.

Artículo 20. Relaciones entre el responsable y el encargado del tratamiento. 1. El acceso a los datos por parte de un encargado del tratamiento que resulte necesario para la prestación de un servicio al responsable no se considerará comunicación de datos, siempre y cuando se cumpla lo establecido en la Ley Orgánica 15/1999, de 13 de diciembre y en el presente capítulo. El servicio prestado por el encargado del tratamiento podrá tener o no carácter remunerado y ser temporal o indefinido. No obstante, se considerará que existe comunicación de datos cuando el acceso tenga por objeto el establecimiento de un nuevo vínculo entre quien accede a los datos y el afectado. 2. Cuando el responsable del tratamiento contrate la prestación de un servicio que comporte un tratamiento de datos personales sometido a lo dispuesto en este capítulo deberá velar por que el encargado del tratamiento reuna las garantías para el cumplimiento de lo dispuesto en este Reglamento. 3. En el caso de que el encargado del tratamiento destine los datos a otra finalidad, los comunique o los utilice incumpliendo las estipulaciones del contrato al que se refiere el apartado 2 del artículo 12 de la Ley Orgánica 15/1999, de 13 de diciembre, será considerado, también, responsable del tratamiento, respondiendo de las infracciones en que hubiera incurrido personalmente. No obstante, el encargado del tratamiento no incurrirá en responsabilidad cuando, previa indicación expresa del responsable, comunique los datos a un tercero designado por aquél, al que hubiera encomendado la prestación de un servicio conforme a lo previsto en el presente capítulo. Artículo 21. Posibilidad de subcontratación de los servicios. 1. El encargado del tratamiento no podrá subcontratar con un tercero la realización de ningún tratamiento que le hubiera encomendado el responsable del tratamiento, salvo que hubiera obtenido de éste autorización para ello. En este caso, la contratación se efectuará siempre en nombre y por cuenta del responsable del tratamiento. 2. No obstante lo dispuesto en el apartado anterior, será posible la subcontratación sin necesidad de autorización siempre y cuando se cumplan los siguientes requisitos:

1. Que se especifiquen en el contrato los servicios que puedan ser objeto de subcontratación y, si ello fuera posible, la empresa con la que se vaya a subcontratar.  Cuando no se identificase en el contrato la empresa con la que se vaya a subcontratar, será preciso que el encargado del tratamiento comunique al responsable los datos que la identifiquen antes de proceder a la subcontratación.
2. Que el tratamiento de datos de carácter personal por parte del subcontratista se ajuste a las instrucciones del responsable del fichero.
3.  Que el encargado del tratamiento y la empresa subcontratista formalicen el contrato, en los términos previstos en el artículo anterior.

En este caso, el subcontratista será considerado encargado del tratamiento, siéndole de aplicación lo previsto en el artículo 20.3 de este reglamento. 3. Si durante la prestación del servicio resultase necesario subcontratar una parte del mismo y dicha circunstancia no hubiera sido prevista en el contrato, deberán someterse al responsable del tratamiento los extremos señalados en el apartado anterior. En los aspectos de seguridad del R. D. se tiene: Artículo 82. Encargado del tratamiento. 1. Cuando el responsable del fichero o tratamiento facilite el acceso a los datos, a los soportes que los contengan o a los recursos del sistema de información que los trate, a un encargado de tratamiento que preste sus servicios en los locales del primero deberá hacerse constar esta circunstancia en el documento de seguridad de dicho responsable, comprometiéndose el personal del encargado al cumplimiento de las medidas de seguridad previstas en el citado documento. Cuando dicho acceso sea remoto habiéndose prohibido al encargado incorporar tales datos a sistemas o soportes distintos de los del responsable, este último deberá hacer constar esta circunstancia en el documento de seguridad del responsable, comprometiéndose el personal del encargado al cumplimiento de las medidas de seguridad previstas en el citado documento. 2. Si el servicio fuera prestado por el encargado del tratamiento en sus propios locales, ajenos a los del responsable del fichero, deberá elaborar un documento de seguridad en los términos exigidos por el artículo 88 de este reglamento o completar el que ya hubiera elaborado, en su caso, identificando el fichero o tratamiento y el responsable del mismo e incorporando las medidas de seguridad a implantar en relación con dicho tratamiento. 3. En todo caso, el acceso a los datos por el encargado del tratamiento estará sometido a las medidas de seguridad contempladas en este reglamento.

Es de destacar lo apostillado en el artículo 22, donde obliga de alguna manera al responsable de los datos a ejercer como tal y controlar el cumplimiento de sus prestadores en la frase "Cuando el responsable del tratamiento contrate la prestación de un servicio que comporte un tratamiento de datos personales sometido a lo dispuesto en este capítulo deberá velar por que el encargado del tratamiento reuna las garantías para el cumplimiento de lo dispuesto en este Reglamento." sobre todo, en lo referente a la seguridad de la información. Así que de nuevo, el cumplimiento de la protección de datos puede ser una buena escuela para hacer las cosas como Dios manda. Está muy bien eso de ceder el marrón a un tercero, pero esa delegación no exime de responsabilidad. Si eres el que cede o transfiere el riesgo, la adecuada gestión es verificar que ese tercero estará a la altura de las circunstancias y que los servicios que presta, reunen las garantías mínimas necesarias para salvaguardar tus intereses. 

Por que de lo contrario, cuando el Responsable de Seguridad vaya a comprobar qué ha pasado, podrá encontrarse al Steve Urkel de turno diciendo ¿he sido yo? y la cabeza a cortar será la que quien contrató un servicio inadecuado.

La importancia del análisis del riesgo dentro del SGSI

Desde junio de este año, ya contamos con una nueva norma dentro de la serie ISO 27000. Se trata de quizás, una de las normas más estructurales de la serie ya que establece un criterio sobre la gestión del riesgo y proporciona un marco normalizado que nos puede ayudar a definir nuestra propia metodología y que tiene por título
ISO/IEC 27005:2008, Information technology -- Security techniques -- Information security risk management.

El análisis del riesgo es crucial para el desarrollo y operación de un SGSI. Aunque se habla mucho del tema, en esta fase la organización debe construir lo que será su "modelo de seguridad", una representación de todos sus activos y las dependencias que estos presentan frente a otros elementos que son necesarios para su funcionamiento (edificios, suministros, sistemas informáticos, etc.) y su mapa de amenazas (una hipótesis de todo aquello que pudiera ocurrir y que tuviera un impacto para la organización).

Es habitual, dada todavía la poca experiencia que existe en empresas sobre la seguridad que el análisis de riesgos lo realice la consultora externa que apoya en el proceso de implantación. Sin embargo, es muy importante que la empresa se involucre en esta actividad y entienda cómo se ha realizado este análisis. Sobre todo porque en el segundo ciclo del SGSI, se debe revisar éste análisis por si han habido cambios. Por hacer un simil que se entienda, el análisis de riesgos es como la visita al doctor para que nos identifique una enfermedad. Se realizan una serie de actividades como son: identificación de activos, identificación de amenazas, estimación de impactos y vulnerabilidades y con todo ello ya se puede calcular el riesgo. Pero éste diagnóstico es válido sólo para ese momento puntual en el tiempo. No es algo estático sino que va a cambiar a lo largo del tiempo: nuevos activos, nuevas amenazas, modificación en la ocurrencia de las amenazas (pensar por ejemplo en el caso del phishing como esta amenaza ha pasado a ser extremadamente frecuente en este último año). Por tanto, cada año la organización debe replantearse su diagnóstico y cuestionarse si tiene nuevos sintomas o si los sintomas detectados han sido ya mitigados y se pueden tratar otras carencias de menor importancia. La mejora continua afecta también al riesgo ya que si los niveles más altos se han solucionado, lo lógico es plantearse para el siguiente año atacar los siguientes.

Es curioso además comprobar como la "gestión del riesgo de la seguridad " empieza a ser vista con buenos ojos por otras áreas que se dedican a gestionar el riesgo. Hablo por ejemplo del caso de las entidades financieras que en virtud a Basilea II deben tratar el riesgo operacional. La tecnología es un riesgo operativo, y en algunas organizaciones el área de seguridad ha entrado a formar parte de la gerencia de riesgos, así como ahora el área de seguridad está entrando a formar parte en las empresas del compliance.

En este área nueva, existe un gran interés estudiar y comprender mejor el concepto del riesgo. Yo tengo un especial cariño a esta actividad porque fue por la que me introduce en esto de la seguridad hace ya casi diez años probando la primera versión de MAGERIT. Desde entonces el enfoque y la madurez de esta actividad ha cambiado y mejorado mucho, tratando de huir de la subjetividad de las valoraciones para llegar a un proceso formal, metódico y racional de valoración del riesgo.
Gracias a www.iso27000.es he podido dar con FAIR. Esta aproximación trata de ofrecer las bases fundamentales del proceso, una descripción de los conceptos a utilizar, así como un marco para la realización de análisis de riesgos. Es importante señalar que gran parte del marco FAIR puede utilizarse para reforzar, en lugar de sustituir, los procesos de análisis de riesgos basados en metodologías tan conocidas como OCTAVE, MAGERIT, MEHARI. Esta documentación se puede descargar en FAIR.

La Agencia Europea para la Seguridad de la Información (ENISA) dispone en el siguiente enlace de un inventario de las metodologías más conocidas que existen en torno a este tema que se puede consultar en este enlace.

Otra de las cosas más atractivas de esta actividad, el análisis y la gestión del riesgo es su faceta psicológica. El riesgo se define en el diccionario como la proximidad a un daño. Formalmente sería el factor que pondera la vulnerabilidad frente a una amenaza y el impacto que puede ocasionar. Navegando he podido encontrar un texto curioso sobre esa gestión inconsciente que hacemos los humanos del riesgo.

Fuente: Teoría de compensación del riesgo.

La causa de esta aparente contradicción fue desvelada hace más de veinte años por varios psicólogos especializados en tráfico, especialmente en Canadá y en los países escandinavos, mediante la teoría conocida como la “Compensación del riesgo” 1. Según esta teoría, cualquier persona situada en un entorno de riesgo adapta su comportamiento a los cambios del nivel de riesgo que percibe. Si detecta un riesgo creciente, actuará de forma más cautelosa, y si por el contrario detecta un riesgo decreciente, se comportará de un modo más despreocupado. De este modo “compensa” los cambios del nivel de riesgo, volviendo a situarse en el nivel de riesgo que considera aceptable, que normalmente es variable para cada persona.

En el caso concreto del tráfico, ello supone que si los conductores son conscientes de que llevan un coche con más equipamiento de seguridad, o de que circulan por vías más seguras, muchos de ellos tenderán a utilizar más el automóvil, y sobre todo, a realizar una conducción más arriesgada. Estos conductores “aprovecharán” la reducción del riesgo que han percibido para satisfacer algún deseo personal: ganar tiempo, practicar una conducción más excitante, probar las prestaciones del automóvil, etc..

Puede ocurrir que algunos de estos conductores sobrevaloren la reducción de riesgo que les ofrece un nuevo automóvil o una nueva carretera. En tal caso, se puede dar la paradoja de que estos conductores se acaben situando en niveles de riesgo efectivo más elevados que en la situación anterior. La influencia de estos grupos de riesgo incrementado puede hacer que, estadísticamente, los resultados globales de seguridad vial no mejoren, aunque la sociedad haya realizado grandes inversiones en viario, o en nuevos automóviles. Esto es lo que, en términos muy generales y orientativos, puede estar pasando en España y en otros países en los últimos años.

Estos hechos podrían ser encajados dentro de algunas de las Máximas de Seguridad que Bruce Schneier ha posteado hace unos días y que también ha comentado Sergio Hernando. Me quedo con la misma que se queda Sergio y otra mas:
Backwards Maxim: Most people will assume everything is secure until provided strong evidence to the contrary--exactly backwards from a reasonable approach. (la mayoría de la gente asumirá que todo es seguro hasta que se les muestren evidencias significativas de lo contrario, justo lo contrario de lo que sugiere una aproximación razonable)

Arrogance Maxim: The ease of defeating a security device or system is proportional to how confident/arrogant the designer, manufacturer, or user is about it, and to how often they use words like "impossible" or "tamper-proof". (La facilidad de atacar un dispositivo o sistema de seguridad es proporcional a la confidencialidad/arrogancia del diseñador, fabricante o responsable de seguridad y a la frecuencia con la que éstos usan palabras como "imposible" or "impenetrable".