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:

Canaima GNU/Linux 4.0 (beta1)
Luego de diez semanas de desarrollo después del lanzamiento de la versión alfa del Sistema de Operación Canaima GNU/Linux 4.0, tenemos el agrado de informar que ya se encuentra disponible la primera versión beta (para pruebas) de Canaima GNU/Linu...
Ubuntu vs Windows
Muchas personas hemos oido hablar muy bien sobre el uso de linux en un ordenador de escritorio pero no se atreven a hacer la migración. Intentaré mostrar en este artículo cómo funciona un escritorio de Linux apuntando las similitudes con el de Wi...
Conferencias virtuales gratuitas UMEET 2003 sobre Unix
El próximo lunes día 15 de Diciembre se inicia el ciclo de conferencias virtuales UMEET 2003, organizadas por UniNet. Se trata del cuarto año de vida de la iniciativa, y cuenta con una gran aceptación entre los usuarios. ...
Microsoft corrige 14 vulnerabilidades en PowerPoint
Este martes pasado Microsoft ha publicado sólo un boletín de seguridad (el MS09-017) correspondientes a su ciclo habitual de actualizaciones. Esta actualización que corrige un total de 14 vulnerabilidades presenta, según la propia clasificación ...
Los usuarios de Facebook han sido más negligentes en 2009, según Sophos
La firma de seguridad TI Sophos ha anunciado los resultados de su última prueba para demostrar lo sencillo que resulta robar identidades vía Facebook y asegura que de ella se deduce que la negligencia de los usuarios ha sido mayor en 2009. El 46% d...
Bug Zero-day encontrado en Adobe Flash
Los cazadores de malware han descubierto una vulnerabilidad del tipo zero-day en Adobe Flash. El problema ha sido añadida a la versión china del Mpack exploit kit y hay señales de que los explits están siendo inyectados en sitios web de terceros ...
0 day en Adobe Acrobat
Adobe ha confirmado que existe otra grave vulnerabilidad en Adobe Reader que parece estar siendo aprovechada por atacantes para ejecutar código en el sistema (tanto Windows como cualquier otro sistema operativo que lo soporte)....
Microsoft lanza un parche por una vulnerabilidad
Microsoft ha puesto a disposición de los clientes con Windows un parche de seguridad que debe ser instalado de forma inmediata. La compañía ha explicado que se han detectado certificados no autorizados obtenidos a través de dos de sus entidades d...
A pesar del Cloud Computing, es necesario instalar Software antimalware
David Perry, con una dilatada experiencia de más de 25 años, está considerado uno de los mejores expertos mundiales en el campo del hacking, virus, malware y cibercrimen. Además, ha sido asesor de la Casa Blanca y es autor y conferenciante muy po...
Microsoft, ¿No quedamos en dejar de utilizar MD5? (I)
Cesar Cerrudo ha presentado un método que podría ser usado para elevar privilegios en Windows de forma relativamente sencilla. Solo es necesario realizar un ataque second-preimage. O sea, A partir de un fichero de sistema, crear otro con un mis...

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