Cómo escribir una Política de Seguridad de la Información


Una Política de Seguridad de la Información es la piedra angular del Programa de Seguridad de la Información de todo CSO. Debe reflejar los objetivos de seguridad de la compañía y establecer la estrategia de gestión acordada para asegurar la información. En este artículo explicamos cómo dar el primer paso, qué debe cubrir y y cómo elaborar una política de seguridad de la información efectiva.





Para que la Política de Seguridad de la Información sea útil y permita ejecutar el resto del Programa de Seguridad de la Información debe ser aceptada formalmente por la dirección ejecutiva de la empresa. Esto significa que para elaborar un documento de política de seguridad la organización debe tener unos objetivos de seguridad bien definidos y una estrategia de gestión de seguridad de la información previamente aceptada. Si se abre un debate sobre los contenidos de la política, se extenderá a cada intento de ponerla en práctica, con la consecuencia de que el propio Programa de Seguridad de la Información quedará invalidado.

Políticas "empaquetadas"

Hay un montón de productos de "política de seguridad empaquetada" en el mercado, pero pocos de ellos obtendrán el placet de la dirección ejecutiva sin que tengan que ser detallados paso a paso por un profesional de la seguridad. No es probable que esto ocurra debido a la falta de tiempo inherente a la directiva empresarial. Aunque fuera posible que los directivos aceptasen unas políticas “adquiridas”, tampoco es la opción correcta para conseguir que los gestores de la empresa piensen en la seguridad. En vez de ello, el primer paso para elaborar una política de seguridad es averiguar cómo ve la seguridad la dirección de la empresa. Como la política de seguridad es, por definición, un conjunto de mandatos de gestión respecto a la seguridad de la información, estos mandatos proporcionan la guía de trabajo del profesional de seguridad. Si el profesional de seguridad solicita a la directiva que firme dichos mandatos, probablemente los pasarán por alto.

Un profesional de seguridad cuyo trabajo es elaborar la política de seguridad debe asumir por tanto el rol de absorber y escribir lo que le transmite la dirección ejecutiva de la empresa. Debe saber escuchar y tener en cuenta los contenidos de sus conversaciones sin importar la disparidad de conocimientos de cada ejecutivo. También debe trasladarlo a documentos que contengan de forma fidedigna lo que le transmiten sin embellecerlo ni añadir anotaciones. Debe ser capaz de detectar los asuntos que preocupan a través de entrevistas a los directivos y preparar una declaración positiva sobre cómo quiere la empresa proteger su información de forma global. El tiempo y el esfuerzo dedicados a obtener el consenso de los ejecutivos sobre la política merecerá la pena porque beneficiará al proceso de implantación de dicha política.

Algunas preguntas que debe hacer el CSO a los directivos

- ¿Cómo describiría los diferentes tipos de información con los que trabaja? - ¿En qué tipo de informaciones suele apoyarse para tomar decisiones? - ¿Hay algún tipo de información que requiera mayor privacidad que otros?

A partir de estas preguntas se puede desarrollar un sistema de clasificación de la información (por ejemplo información de clientes, financiera, de marketing, etc.) y se pueden describir procedimientos apropiados de gestión para cada uno a nivel de proceso de negocio. Por cierto, si se incluyen textos del tipo "se pueden admitir excepciones a esta política contactando al ejecutivo a cargo de…" en la política o en el programa donde está incluida, el documento pierde totalmente su sentido.

En lugar de representar el compromiso de la directiva con el Programa de Seguridad de la Información transmite la sensación de que la política no es factible. El CSO debe preguntarse si se permitirían excepciones parecidas, por ejemplo, en la política de Recursos Humanos o Contabilidad. Por ejemplo, supongamos que hay un debate sobre si los usuarios deberían tener acceso a medios extraíbles como dispositivos USB. El CSO puede creer que tal acceso no es necesario, mientras que un directivo de tecnología puede considerar que los departamentos responsables de manipulación de datos deberían tener la posibilidad de transportar datos en cualquier tipo de soporte. A nivel de política, la opción de consenso podría dar lugar a una frase del tipo: "el acceso a dispositivos extraíbles deberá ser aprobado por el responsable correspondiente"”. Los detalles de los procesos de aprobación utilizados por dicho ejecutivo podrían dar lugar a debate, y continuar las discusiones sobre el asunto. La declaración correcta debería prohibir el uso de esos dispositivos a "cualquiera que no tenga la conformidad de un ejecutivo responsable que apruebe el proceso para utilizarlos".

Políticas distribuidas

En organizaciones muy grandes los detalles sobre las alternativas de conformidad con la política pueden diferir enormemente. En estos casos puede ser apropiado segregar las políticas en función de la audiencia objetiva. Entonces la política empresarial se convierte en una política global que incluye sólo los mandatos de seguridad mínimos y comunes a todos. Los distintos departamentos pueden publicar sus propias políticas. Estas políticas distribuidas son más efectivas cuando la audiencia es un subconjunto bien definido de la organización. En este caso no se necesita el mismo nivel de compromiso por parte de la alta directiva para poder actualizar estos documentos. Por ejemplo, la política de operaciones en Tecnologías de la Información podría requerir solamente la aprobación del director de ese departamento, siempre y cuando esa política sea consistente con la política global de seguridad y sólo aumente el compromiso de los directivos con la estrategia de seguridad general. Presumiblemente debería citar a dichos responsables como “sólo los administradores autorizados podrán disponer de acceso para implementar cambios de configuración en el sistema operativo” y “sólo se tendrá acceso a las contraseñas de los ID genéricos en el caso de cambios autorizados en los procesos de control”, por ejemplo. Otros tipos de sub-políticas pueden implicar a personas de diferentes departamentos dedicados a alguna actividad inusual sujeta a controles de seguridad similares, como procesamiento de información de outsourcing o encriptación de comunicaciones por correo electrónico.

Documentos a incluir en el Programa de Seguridad de la Información

-Roles y responsabilidades: descripción de las responsabilidades de seguridad para otros departamentos. Por ejemplo, se le puede dar al departamento de desarrollo la tarea de evaluar las vulnerabilidades de seguridad antes de desplegar nuevas aplicaciones; o al departamento de recursos humanos la labor de mantener listas actualizadas de empleados y suministradores. -Estándares tecnológicos: descripción de los parámetros de configuración técnica y valores asociados que se hayan determinado para asegurar que los directivos pueden controlar el acceso a los activos de información electrónica. -Procesos: flujos de trabajo que muestren cómo se combinan las funciones de seguridad desarrolladas por los diferentes departamentos para asegurar la gestión segura de la información. -Procedimientos: instrucciones paso a paso para que el personal pueda realizar tareas rutinarias de seguridad sin necesidad de formación previa, y asegurar así que los mecanismos preventivos, de detección y/o respuesta funcionan como está previsto. -Directrices: consejos sobre la forma más fácil de cumplir las políticas de seguridad, generalmente redactados para usuarios sin conocimientos técnicos que tienen distintas opciones de gestionar la información de forma segura.

Por otro lado, el hecho de que haya políticas específicas que se apliquen a todos los usuarios no debería provocar que se elaboren nuevas políticas, pero sí deberían añadirse a la política global como “secciones”. No es conveniente tener múltiples políticas que contengan mandatos para toda la empresa porque cuantas más políticas haya más complicado es conseguir que todo el mundo tenga un conocimiento adecuado del nivel de seguridad correcto. Ya es suficientemente difícil establecer programas de información sobre las políticas de seguridad que lleguen a todos los destinatarios sin tener que aclarar por qué se crearon distintos documentos de política de seguridad en lugar de uno solo. Por ejemplo, que se impongan nuevas restricciones al acceso a Internet no implica que se cree un nuevo documento de política de seguridad. Otro inconveniente de la creación de sub-políticas es que no deben repetir los contenidos de la política global, y al mismo tiempo deben ser consecuentes con ella. Debería estar prohibida la repetición, ya que permitiría que los diferentes documentos estuvieran desincronizados según van evolucionando. En lugar de eso, los sub-documentos deben hacer referencia al documento global y estar enlazados a él de manera que le quede claro al lector.

Siempre que haya una directiva de seguridad de la información que pueda ser interpretada de diferentes formas debería ser cuestionada por el CSO. Las políticas deben ser órdenes. Las estrategias de implementación alternativas pueden ser citadas como guías, procedimientos, procesos o responsabilidades, pero no pueden ser políticas. Esto permite que se pueda innovar y disfrutar de cierta flexibilidad en el departamento al tiempo que se mantienen unos firmes objetivos de seguridad a nivel de política.

Esto no significa que haya que eliminar los objetivos de protección de la información del Programa de Seguridad de la Información. Se trata de que no toda la estrategia de seguridad se puede documentar a nivel de política de obligado cumplimiento. Según el Programa de Seguridad de la Información vaya madurando se puede ir actualizando la política, pero no necesariamente para ganar mejoras incrementales en seguridad. Se puede mejorar el consenso usando otros documentos dentro del Programa de Seguridad de la Información.

Qué debe contener una Política de Seguridad La pregunta es ¿cuál es la información mínima necesaria que se debe incluir en una Política de Seguridad? Debe ser suficiente para comunicar a los directivos los objetivos y la dirección en la que debe ir la seguridad. Debe incluir lo siguiente:

1. Alcance: debe incluir toda la información, sistemas, instalaciones, programas, datos, redes y usuarios de tecnología de la empresa, sin excepción.

2. Clasificación de la información: debe proporcionar definiciones específicas para cada tipo de contenido, y no simplemente adjetivos como “confidencial” o “restringida”.

3. Objetivos para el manejo seguro de la información en cada categoría (por ejemplo, se deben combinar las obligaciones contractuales, regulatorias y legales en uno.

4. Posicionamiento de la política de seguridad en el contexto de las demás directivas de gestión y otros documentos suplementarios (es decir, si ha sido acordada a nivel ejecutivo, todos los demás documentos de gestión de información deben ser consecuentes con ella).

5. Referencias a los documentos de apoyo (los de roles y responsabilidades, procesos, tecnología, etc.).

6. Instrucciones específicas sobre las obligaciones de seguridad de toda la empresa a nivel general (por ejemplo, todo acceso a cualquier sistema informático requiere la verificación de identidad y la autenticación, no se pueden compartir mecanismos de autenticación, etc.)

7. Designación específica de las responsabilidades establecidas (por ejemplo: el departamento de tecnología es el único proveedor de líneas de telecomunicación autorizado).

8. Consecuencias del incumplimiento (desde sanciones hasta el cese o despido). Esta lista será suficiente como política de seguridad de la información básica para una empresa. Aunque los puntos 6 y 7 pueden contener una gran cantidad de variables y detalles relativos a las medidas de seguridad, es aconsejable no extenderlos demasiado para asegurar su legibilidad, y apoyarse en sub-políticas o documentos de apoyo para incluir todos los requisitos.

De nuevo, es más importante tener una conformidad completa a nivel de política que incluir montones de detalles. Hay que tener en cuenta que el propio proceso de producción de una política de seguridad debe estar fuera de la política. También se debe preservar cuidadosamente la documentación relativa a aprobaciones, actualizaciones y control de versiones de la política de seguridad, y tenerlo disponible por si es necesaria una auditoría del proceso.

Fuente:
Por: Jennifer Bayuk es consultora de seguridad de la información y antigua CISO. Ha escrito y co-editado varios libros, como Enterprise Information Security and Privacy, Stepping Through the IS Audit, 2nd Edition,Stepping Through the InfoSec Program

http://www.csospain.es/



Otras noticias de interés:

Bazaar se convierte en un proyecto GNU
Bazaar, el sistema de control de versiones distribuído (VCS) de Canonical Ltd. escrito en Python, se convirtió en parte del proyecto GNU. ...
Un llamado a la gente de linux.org.ve
Este el sitio de linux.org.ve , se describe como Grupo de usuarios Linux de Venezuela, además de apoyar el software libre (GNU). Pero no han respetado los derechos de autor del c...
El pinguinito de la mano de IBM
El gigante azul uno de los grandes del mundo de la tecnología, anunció en su evento experiencias reales, soluciones reales, para negocios reales que refuerza su compromiso con Linux. ...
Alerta de Spyware: CoolWebSearch (CWS)
na de las características de este spyware, es que el mismo se transforma muy rápidamente. A continuación se detallan algunas de las variantes y su fecha aproximada de aparición, en orden cronológico inverso: º DNSRelay.dll ? ...
IE8, casi obligatorio . ¿Adiós, IE6?
El nuevo navegador de Microsoft parece querer implantarse claramente en todas las ediciones del sistema operativo de Redmond y para ello sus responsables harán que su actualización sea especialmente relevante tanto para Vista, como, sobre todo, par...
Actualización de Joomla, 1.5.18, corrige vulnerabilidad XSS
El equipo de seguridad de Joomla ha anunciado la inmediata disponibilidad de la versión de seguridad 1.5.18 que corrige una seria vulnerabilidad XSS afectando a la versión 1.5.7 y todas las anteriores de la rama 1.5x....
Por qué no debemos usar la misma contraseña?
El pasado fin de semana, Evernote vio comprometida la seguridad del servicio tras detectar una intrusión que habría tenido acceso a nuestros nombres de usuario, correos electrónicos y también a las contraseñas aunque, afortunadamente, éstas est...
Google parchea Chrome 11 de 27 vulnerabilidades
Google ha lanzado la versión estable de Chrome 11, en la que parchea 27 vulnerabilidades. El nuevo navegador está disponible para Windows, Mac y Linux....
Actualización de seguridad de Adobe Shockwave
Actualizar a la última versión del programa, para corregir los fallos. A través de la página oficial de instalación de Adobe Shockwave Player , se puede descargar la última versión del programa....
Denegación de servicio en eMule
Se ha descubierto una vulnerabilidad en eMule que puede ser explotada por usuarios malintencionados para provocar una denegación de servicio....

Brindanos
un o una


Redes Sociales

Publicidad


Gana Bitcoins desde tu casa

Categorías


Planeta Vaslibre

Blog Roll




Nube de tags

  • anonimato
  • anonimo
  • antivirus
  • apache
  • blog
  • bsd
  • bug
  • centos
  • chrome
  • cifrado
  • computer
  • debian
  • escribir
  • exploits
  • fedora
  • fice
  • firefox
  • forense
  • freebsd
  • gentoo
  • github
  • gnome
  • gnu
  • gpl
  • gtk
  • hack
  • hacking
  • hosting
  • informacion
  • informatica
  • internet
  • isos
  • libre
  • licencias
  • linux
  • linuxmint
  • lxde
  • micros
  • mint
  • mit
  • mozilla
  • mysql
  • noticia
  • opensource
  • pgp
  • php
  • politica
  • sabayon
  • seguridad
  • system
  • tecnologia
  • thunar
  • thunderbird
  • tor
  • troyanos
  • tware
  • ubuntu
  • underground
  • vaslibre
  • virus
  • viserproject
  • vivaldi
  • vulnerabilidades
  • web
  • website
  • windows
  • xanadu
  • xfce
  • xombra