Políticas de Seguridad

POLÍTICAS DE SEGURIDAD DE LA INFORMACIÓN

FIST Conferences

Consejo Superior de Investigaciones Científicas

Febrero de 2007

Estructura de la Política

Contenido de la Política

Consideraciones adicionales

Evaluación de cumplimiento

Ejemplo

Introdución

SANS Policy Project


FIST Conferences


Febrero de 2007

La complejidad de las organizaciones y la dificultad para gestionar la infraestructura IT ha revelado la necesidad de establecer y uniformar requerimientos mínimos para el gobierno de dicha infraestructura.

El cumplimiento de dichos requerimientos asegura la consecución de un nivel de riesgo aceptable en la organización.

La Política de Seguridad de la organización especifica los requerimientos que deben satisfacerse para proteger los activos de información.

La Política de Seguridad se traslada a una colección de documentos que abordan diferentes temas con diferente nivel de detalle (estructura).

Los documentos se actualizan periódicamente, a medida que ocurren cambios significativos en la organización.

Introducción


FIST Conferences


Febrero de 2007

Para entender por qué es necesaria una Política de Seguridad, se pueden plantear las siguientes preguntas:

¿Qué medidas de seguridad existen actualmente en los servidores?

¿Es suficiente la configuración establecida para el antivirus?

¿Quién concede los accesos a los usuarios en los diferentes entornos?

¿Quién revoca dichos accesos cuando dejan de ser necesarios?

¿Cómo se protege la confidencialidad de la información en tránsito?

¿Cómo se gestionan los incidentes de seguridad?

¿Cómo se garantiza la seguridad de las relaciones con teceros?

¿Cómo se previene la fuga de información por parte de usuarios finales?

Introducción


FIST Conferences


Febrero de 2007

Las siguientes son situaciones clásicas en las organizaciones con una dependencia tecnológica notable:

No se revocan los accesos de usuarios que ya no pertenecen a la organización o que han cambiado de departamento.

Hay sistemas con contraseñas por defecto, en blanco o que no cumplen los requerimientos mínimos de complejidad.

Los incidentes de seguridad se gestionan ad-hoc, involucrando a las personas que se consideran más apropiadas en cada caso.

No se monitorizan los logs de los sistemas, por lo que muchos incidentes de seguridad pasan completamente desapercibidos.

Las aplicaciones propietarias se desarrollan sin tener en cuenta la seguridad, en ocasiones por parte de terceros.

Introducción


FIST Conferences


Febrero de 2007

La organización clásica es piramidal en tres niveles, cada uno de los cuales presenta un formato y un nivel de detalle diferentes.



FIST Conferences


Febrero de 2007

El primer nivel se compone de una declaración formal del compromiso de la organización con la protección de los activos de información.

En este documento se señala el alcance y los objetivos de seguridad que se pretenden lograr con la implantación de la política.

Es elaborado por la Alta Dirección y distribuida a todos los estratos de la compañía, a través de comunicaciones oficiales.

No se incluye ningún detalle acerca de la forma de alcanzar los objetivos o el planteamiento concreto de los controles de seguridad.



FIST Conferences


Febrero de 2007

En el segundo nivel se incluyen documentos que describen requerimientos generales en relación con cada una de las áreas o componentes del IT de la organización.

Dichos requerimientos particularizan y articulan los objetivos indicados en el nivel anterior.

Un caso particular de este nivel son los procedimientos, que especifican secuencias de pasos o circuitos en una determinada función IT.

No deben confundirse con los manuales de instalación o administración de los elementos de la infraestructura tecnológica (howtos).



FIST Conferences


Febrero de 2007

El tercer nivel está formado por una colección de documentos con requerimientos detallados o estándares.

Los requerimientos aplican a componentes, estructuras o procesos individuales, que forman parte de los componentes, estructuras y procesos a los que se refieren los documentos del nivel anterior.

Pueden especificar la configuración de un producto de seguridad, un checklist de opciones del SO o el criterio de evaluación de proveedores.



FIST Conferences


Febrero de 2007

Primer nivel:

Política Global de Seguridad.

Segundo nivel:

Elementos de Seguridad en Sistemas Servidor.Estrategia de Protección frente a Software Malicioso.Contratación de Servicios IT en Régimen de Outsourcing.Administración de Perfiles, Usuarios y Privilegios.Desarrollo Seguro de Software.

Ejemplos de documentos de cada nivel


FIST Conferences


Febrero de 2007

Ejemplos de documentos de cada nivel

Procedimientos:

Alta o Baja de Usuarios en Entornos Críticos.Requisitos de Seguridad en el Desarrollo de Sistemas.Gestión de Peticiones de Seguridad.Gestión de Incidentes de Seguridad.

Tercer nivel:

Acceso Remoto VPN/SSL.Seguridad de Redes Wi-Fi.Seguridad de Redes VoIP.Seguridad de Terminales en Entorno Mainframe.Configuración Segura de Servidores Windows 2000.


FIST Conferences


Febrero de 2007

Debe cubrir, al menos las siguientes áreas:

Contenido de la Política

Código malicioso

Redes WI-FI

Servidores

Uso aceptable de e-mail e Internet

Seguridad VoIP

Acceso remoto

Gestión de incidentes

Entornos legacy

Estaciones de trabajo

Outsourcing y terceros

Pruebas de intrusión

Usuarios y privilegios

Formación y concienciación

Programación segura

Gestión de vulnerabilidades

Dispositivos de interconexión

Análisis de riesgos

Estrategia antispam

Adquisición de productos

Uso de portátiles

Líneas analógicas

Nomenclatura de usuarios

Seguridad de CPDs

Prevención deintrusiones


FIST Conferences


Febrero de 2007

La estructura y el contenido de la política dependen fuértemente de las características de la organización en el que se desarrolla.

Un factor clave: el grado de madurez de los procesos de gestión IT.

Las organizaciones con mayor madurez elaborarán un cuerpo normativo:

Más ambicioso.Con requerimientos más específicosCentrado en la formalización de procesos y controles ya implantados.

Las empresas con menor madurez en esta área comenzarán con:

Una política de seguridad sencillaFijando requisitos básicos.Esfuerzo en la definición de quick wins.

Características de la organización


FIST Conferences


Febrero de 2007

Estructura de la organizaciónLíneas de negocio, presencia geográfica, estrategia IT, relevancia del Departamento de Seguridad en la organización, etc.

Grado de dependencia de las Tecnologías de la Información.

Relación con tercerosExternalización de procesos o áreas (producción de software, gestión de dispositivos de red, seguridad), de perfiles funcionales (administradores de sistemas, consultores, auditores) o de servicios (tests de intrusión, monitorización de seguridad, DRP).

Grado de conocimiento y concienciación de la Alta Dirección y de los usuarios finales en el área de seguridad IT.

Características de la organización


FIST Conferences


Febrero de 2007

El contenido debe ser sintético y centrado en los requisitos mínimos, sin descripciones superfluas que los justifiquen.

Es frecuente cometer el error de introducir información relevante:

Descripción del elemento, estructura o proceso al que aplica el requerimiento (features del software antivirus).

Justificación del requerimiento (ventajas de la segregación de entornos en el proceso de producción de software).

Propuesta para satisfacer el requerimiento (indicación de las fuentes de actualizaciones o parches de sistemas operativos).

Presentación del contenido


FIST Conferences


Febrero de 2007

El contenido debe contrastarse con los departamentos afectados por cada uno de los documentos.

Permite evaluar la dificultad de implantación de los requerimientos y adaptarlos a las características particulares de la organización.

Como resultado de la interacción:

Incorporación de nuevos requerimientos no previstos originalmente.

Eliminación de requerimientos con un análisis coste-beneficio desfavorable o no aplicables.

Simplificación del contenido.

Definición conjunta de un roadmap para la imlementación de procesos o soluciones tecnológicas que satisfagan requerimientos críticos.

Participación de otros departamentos


FIST Conferences


Febrero de 2007

Los documentos deben evolucionar para incrementar progresivamente el nivel de seguridad global.

Si Política de Seguridad que permanece estática, no ha sido bien diseñada.

Los documentos deben tener un carácter dinámico, con un incremento gradual del nivel de seguridad considerado aceptable.

La frecuencia de cambio/revisión recomendados varía en función del tipo de documento.

De esta manera se transforma progresivamente la organización, partiendo de un baseline o nivel inicial basadon en quick wins, que evoluciona hacia un modelo de seguridad cada vez más maduro.

Ciclo de vida de los documentos


FIST Conferences


Febrero de 2007

Tercer nivel

Deberían revisarse y actualizarse al menos una vez al año, o bien cuando se produzca un cambio significativo en los procesos o en la infraestructura tecnológica.

Segundo nivel

Deberían revisarse anualmente, con una frecuencia de cambio inferior: cambios en la estrategia de otros departamentos (Sistemas, Backup, Legal) o en la estructura organizativa (adquisiciones, outsourcing, insourcing).

La declaración formal de la Alta Dirección sólo debería modificarse excepcionalmente.

Frecuencia de cambio y revisión


FIST Conferences


Febrero de 2007

El contenido debe tener en cuenta la audiencia objetivo:

Personal técnicoPersonal de gestiónDirectoresUsuarios

Es un error escribir documentos con requisitos difíciles de asimilar, ambiguos, demasiado técnicos o demasiado generales.

Para facilitar la comprensión del contenido, es recomendable incluir definiciones de términos sujetos a múltiples interpretaciones.

Audiencia de los documentos


FIST Conferences


Febrero de 2007

El inventariado de situaciones de excepción es una herrramienta útil para inventariar riesgos.

En determinados casos no es posible cumplir un requerimiento, por limitaciones técnicas u otras causas justificadas.

La política de excepcionamiento permite inventariar, monitorizar y gestionar estas situaciones a lo largo del tiempo.

Permite a las áreas afectadas conseguir un permiso por parte del Departamento de Seguridad para incumplir el requerimiento.

Primero se debe determinar que el coste o la complejidad asociada al cumplimiento es superior al beneficio obtenido, o bien requiere una inversión que no se puede realizar en la actualidad.

Política de excepcionamiento


FIST Conferences


Febrero de 2007

Es fundamental analizar en detalle cada situación de excepción antes de conceder un permiso para incumplir un requerimiento.

El inventario de excepciones debería utilizarse como entrada a otros procesos, principalmente aquellos relacionados con el análisis de riesgos.

Las excepciones se deben revisar periódicamente, para asegurarse de que la situación que originó la excepción se mantiene en la actualidad.

Política de excepcionamiento


FIST Conferences


Febrero de 2007

Los documentos debe tener en cuenta la clasificación de activos.

Incluye sistemas, servicios, aplicaciones, bases de datos, documentos e instalaciones de la organización.

Permite establecer diferentes requerimientos de seguridad en función de la criticidad del activo.

De esta forma se consigue un nivel de seguridad mínimo consistente y uniforme a lo largo de la organización.

El establecimiento de un criterio de clasificación coherente depende del conocimiento que la organización tiene acerca de sí misma.

Clasificación de activos


FIST Conferences


Febrero de 2007

Se pueden emplear los siguientes criterios generales para la definición de las categorías de clasificación:

Requerimientos de confidencialidad, integridad y disponibilidad de la información soportada por o contenida en el activo.

Requerimientos legales y regulatorios (por ejemplo, SOX o LOPD).

Criticidad del proceso de negocio asociado.

Grado de exposición (entorno Internet, Intranet, Extranet, etc.).

Categorías de clasificación


FIST Conferences


Febrero de 2007

La Política de Seguridad debe estar respaldado por un proceso de auditoría periódico que verifica su cumplimiento.

Dicho proceso permite verificar el grado de cumplimiento del mismo en las distintas áreas de la organización.

Para cada requerimiento específico se debe indicar un procedimiento para verificar su cumplimiento y generar las correspondientes evidencias.

Las evidencias pueden ser capturas de pantalla, informes automáticos, actas, autorizaciones firmadas o selladas, etc.

Los resultados obtenidos tras la evaluación de cumplimiento deberían emplearse como entrada de otros procesos relacionados:

Gestión del RiesgoCSA (Control Self-Assessment)Planes Directores

Evaluación de cumplimiento


FIST Conferences


Febrero de 2007

Este proyecto del Instituto SANS constituye un repositorio de políticas que puede faciltar la labor de creación de una Política de Seguridad.

Se diferencian los tres niveles de documentos que se han indicado anteriormente en esta presentación.

La directora del proyecto acumula años de experiencia en la definición e implantación de Políticas de Seguridad en múltiples organizaciones.

18 de los estándares incluidos en el proyecto deben ser cumplidos por organizaciones en el alcance de HIPPAA.

SANS Policy Project


FIST Conferences


Febrero de 2007

Los estándares se organización en las siguientes categorías:

Medidas administrativas

Documented policies and procedures for day-to-day operations; managing the conduct of employees with electronic protected health information; and managing the selection, development, and use of security controls.

Medidas físicas

Security measures meant to protect an organization's electronic information systems, as well as related buildings and equipment, from natural hazards, environmental hazards, and unauthorized intrusion.

Medidas tecnológicas

Security measures that specify how to use technology to protect EPHI, particularly controlling access to it.

SANS Policy Project


FIST Conferences


Febrero de 2007

Es un documento de segundo nivel que especifica lós requerimientos mínimos de seguridad aplicables a servidores.

En este nivel no es relevante el tipo de servidor (Microsoft, UNIX, legacy).

Dichos requerimientos se agrupan en las siguientes categorías:

InstalaciónGestión de usuariosServicios de redSeguridad físicaGeneración de logsCopias de respaldo

Ejemplo: Protección de Servidores


FIST Conferences


Febrero de 2007

Se debe prescindir de la conectividad durante la instalación. En caso de llevar a cabo una instalación en red, se debe utilizar una red aislada.

Se deben seleccionar exclusivamente aquellos paquetes de software necesarios para la prestación de los servicios que se han previsto.

Toda configuración por defecto establecida por aplicaciones software que prestan servicios remotos debe ser adaptada al entorno del servidor.

Se debe instalar un paquete reciente y estable de actualizaciones de seguridad recomendado por el fabricante del sistema operativo.

Debe establecerse una contraseña de administrador robusta.

Protección de Servidores: Instalación


FIST Conferences


Febrero de 2007

Se deben instalar medidas de seguridad que garanticen la adecuación de las passwords de los usuarios a los criterios de complejidad obligatorios.

El mecanismo de autenticación de usuarios debe contemplar medidas para bloquear intentos de acceso no autorizados y facilitar la detección de estos incidentes, limitando su efectividad.

El conjunto de privilegios de que dispone un usuario en el sistema debe ser el mínimo necesario para el ejercicio de sus funciones.

Cuando un usuario ya no necesite acceder al sistema para el ejercicio de sus funciones, se debe revocar su cuenta inmediatamente.

La utilización de cuentas de usuarios reales (asociados a personas) para la ejecución de tareas automáticas está estrictamente prohibida.

Protección de Servidores: Gestión de Usuarios


FIST Conferences


Febrero de 2007

Sólo deben habilitarse aquellos servicios de red que permiten al sistema realizar las funciones para las que ha sido diseñado.

Los servicios que intercambien datos críticos, credenciales o información confidencial deben comunicarse mediante protocolos seguros.

El protocolo empleado debe estar basado en estándares de cifrado reconocidos por la industria.

Protección de Servidores: Servicios de red


FIST Conferences


Febrero de 2007

El sistema servidor debe alojarse en un emplazamiento apropiado.

Cuando el sistema se migre o incorpore a un entorno de producción, preproducción o desarrollo, debe ubicarse en un CPD.

Como parte del diseño, debe contemplarse la posibilidad de que el sistema sea reiniciado de manera accidental.

Protección de Servidores: Seguridad física


FIST Conferences


Febrero de 2007

El servidor debe disponer de un mecanismo de generación y almacenamiento de logs.

Deben figurar los siguientes datos: fecha y hora, subsistema que genera el evento, criticidad, usuario (si aplica).

Se deben registrar las siguientes categorías de eventos:

Autenticación de usuarios, tanto local como remotaCondiciones de error al arrancar servicios de redCondiciones de error en los procesos del sistemaCondiciones de error en los sistemas de comunicacionesÓrdenes de reinicio del sistema o de servicios de redNotificación de supresión de logs

Los registros de log deben ser almacenados de forma segura durante un período de tiempo adecuado.

Protección de Servidores: Generación de logs


FIST Conferences


Febrero de 2007

Se deben realizar de forma periódica copias de respaldo de los datos relevantes almacenados en el servidor y del software propietario instalado, así como de sus datos de configuración.

Las copias de respaldo deben almacenarse en un emplazamiento seguro y suficientemente alejado de los sistemas a los que corresponden.

La frecuencia de realización de las copias está ligada a la frecuencia de actualización de la información que se copia y a la criticidad de los datos.

Protección de Servidores: Copias de respaldo


FIST Conferences


Febrero de 2007

Más información: http://www.rafaelsanmiguel.com

SANS Policy Projecthttp://www.sans.org

¡Muchas gracias!

Políticas de Seguridad

Technology

Transcript of Políticas de Seguridad