Entramos en un capitulo de ISO 27001 con una serie de controles con un fuerte componente técnico.

No olvidemos que una buena utilización de esta guía debe tener en cuenta la aplicación práctica de estas recomendaciones y controles seleccionando aquellos aspectos que puedan aportar un mayor beneficio a la organización siempre bajo el criterio del análisis de riesgos para la seguridad de la información.

Citando la norma:

Objetivo 1:
Procedimientos operacionales y responsabilidades

Se trata de asegurar la operación correcta y segura de las instalaciones de procesamiento de información.

  • 12.1.1 Procedimientos documentados de operación
  • 12.1.2 Gestión de cambios
  • 12.1.3 Gestión de la capacidad
  • 12.1.4 Separación de los ambientes para desarrollo, prueba y operación

Objetivo2:
Protección ante software malicioso

Garantizar que la información y las instalaciones de procesamiento de información se encuentren protegidos contra el código malicioso..

  • 12.2.1 Controles ante software malicioso

Objetivo 3:
Respaldo

Registrar eventos y generar evidencia

  • 12.3.1 Respaldo de la información

Objetivo 4
Registros y supervisión

  • 12.4.1 Registro de eventos
  • 12.4.2 Protección de la información de registros (logs)
  • 12.4.3 Registros del administrador y operador
  • 12.4.4 Sincronización de relojes

Objetivo 5:
Control de software en la producción

Garantizar la integridad de los sistemas operativos

  • 12.5.1 Instalación de software en los sistemas operativos

Objetivo 6:
Gestión de vulnerabilidad técnica

Prevenir la explotación de vulnerabilidades técnicas

  • 12.6.1 Gestión de vulnerabilidades técnicas
  • 12.6.2 Restricciones en la instalación de software

Objetivo 7:
Consideraciones sobre la auditoría de sistemas de información

Minimizar el impacto de las actividades de auditoría en los sistemas operativos

  • 12.7.1 Controles de auditoría de sistemas de información

Objetivo 1: Procedimientos operacionales y responsabilidades

12.1.1 Procedimientos documentados de operación

Los procedimientos deben estar documentados (cuando corresponda) y estar disponibles.

Vamos por partes:

¿Qué debemos documentar?

La documentación de procedimientos al menos debería abarcar aquellas actividades que afectarán al procesamiento de la información y aquellas que la protegen.

Siguiendo este principio deberíamos incluir

  • Los procesos de verificación, instalación, configuración y administración de sistemas y aplicaciones;
  • El procesamiento y manejo de la información;
  • Los procesos de gestión de respaldo de la información, incluidas las pruebas y la verificación de copias de seguridad;
  • La gestión de la programación operacional en el caso de procesos que requieran programación de tiempos
  • De acuerdo con los requisitos de la norma ISO 27001 también deberíamos incluir el manejo de errores y condiciones excepcionales que pueden definirse como incidentes de seguridad.
  • Instrucciones especiales de manejo de medios para información confidencial, incluida la eliminación segura. Recuperación / reinicio del sistema.
  • Los procesos de gestión de registros y elementos de seguimiento de auditoría.
  • Los procedimientos de monitoreo de red y activos de información.

¿Qué significa que estén disponibles?

Esto se traduce en que deberíamos realizar actividades de formación y concienciación sobre los procedimientos sobre el tratamiento de la información y su cuidado o seguridad

12.1.2 Gestión de cambios

Los procesos de cambio pueden conllevar riesgos asociados para la seguridad de la información. Es por ello que la norma nos propone controles para que analicemos los procesos de cambio tanto:

  • Comerciales
  • Instalaciones o infraestructuras (Equipos y Software)
  • Sistemas de procesamiento de información

A estas alturas resulta obvio decir que los controles a establecer para la gestión de cambios serán el resultado del análisis de riesgos y de la aplicabilidad de los controles proporcionados por este anexo.

En resumen podríamos decir que:

Las evaluaciones de riesgos deberían exigir siempre una autorización formal para la realización de cambios.

Otro elemento esencial es establecer siempre una planificación para los cambios a realizar en equipos, sistemas software etc. Acompañado de pruebas realizadas y comunicaciones a todos los involucrados.

Finalmente, deberíamos mantener un registro que contenga al menos la información de:

  • Quien autoriza los cambios
  • Quien realiza los cambios
  • Fecha
  • Descripción de las tareas
  • Validación del cambio
  • Otros

Esta información será útil en una auditoría para proporcionar la confianza de que los cambios se han realizado de forma controlada.

12.1.3 Gestión de la capacidad

Se trata de evitar pérdidas de disponibilidad o rendimiento de los sistemas por falta de capacidad.

Gestionar la capacidad se refiere a tener un control del uso de los recursos. Esto se traduce en controles para:

  • Medición y Seguimiento del uso de recursos
  • Previsión de uso a futuro (prever “cuellos de botella”)
  • Planificar las ampliaciones de capacidad de los recursos cuando sea necesario
  • Optimizar el uso de recursos. P ej. Considere la posibilidad de optimizar las consultas a sus bases de datos, realizar procesos por lotes fuera de horas de carga de trabajo, eliminación de archivos de datos antiguos y aceleración del ancho de banda para accesos no críticos.

12.1.4 Separación de los ambientes para desarrollo, prueba y operación

Este punto nos pone como requisito separar los entornos de desarrollo de los entornos de producción para evitar problemas de indisponibilidad o fallos en el servicio.

Los entornos de desarrollo, código fuente y herramientas de desarrollo, tampoco deberían estar disponibles para los entornos de producción para evitar problemas de seguridad

En cuanto a los datos que se utilizan en entornos de desarrollo no deberían ser una copia de los datos de producción a menos que se hayan previsto controles de seguridad (acuerdos de confidencialidad etc.) similares a los entornos de desarrollo.

Tengamos en cuenta que un desarrollador se encuentra en una posición privilegiada para introducir código malicioso o simplemente código no probado, y ante esto deberíamos tener controles para evitarlo.

Se debe prestar especial atención a la migración del código al entorno operativo con las “pruebas beta” planificadas y la disponibilidad de entornos estables conocidos disponibles por si se encuentran errores.

Objetivo2: Protección ante software malicioso

Garantizar que la información y las instalaciones de procesamiento de información se encuentren protegidos contra el código malicioso...

12.2.1 Controles ante software malicioso

El creciente problema de los ataques contra la seguridad de la información hace que estos controles sean de lo más aplicables y prácticos para cualquier organización.

En primer lugar deberemos disponer de sistemas de detección de código malicioso en los servidores y en los puestos de trabajo.

Requisitos para los Usuarios

La primera línea de defensa para evitar la entrada de código malicioso son los propios usuarios deben estar preparados para saber responder ante posibles incidencias detectadas.

En primer lugar será necesario establecer un procedimiento de seguridad dirigido a los usuarios para que conozcan sus obligaciones respecto a la seguridad de la información y evitemos que abran archivos adjuntos sin asegurarse de que no sean maliciosos, no hagan clic en enlaces en correos electrónicos ni visiten sitios web que puedan cargar virus, troyanos o rastreadores en el dispositivo del usuario etc.

Considere poner en la lista negra sitios conocidos o restringir el uso de internet en los puestos de trabajo si no es necesario para el desempeño de sus funciones.

Requisitos para los Sistemas

La segunda línea de defensa debe enfocarse al acceso a los sistemas para restringir cómo los usuarios conectan medios extraíbles u otros dispositivos a las redes para evitar la introducción de material no verificado.

CASO PRACTICO:

Un dispositivo USB ha estado en muchos lugares podría introducir cualquier cosa aún en sus redes con muchas barreras de seguridad.

Las encuestas nos revelan que la mayoría de los usuarios conectarían un USB que simplemente habían encontrado en cualquier lugar.

Es por ello que debemos tomar medidas tanto de protección como de prevención para este tipo de comportamientos. En este caso la formación de una cultura de la seguridad en las empresas es fundamental

Las medidas de protección para la red son muy útiles, tales como programas antivirus que controlen los archivos que se procesan o envían por correo electrónico.

La desactivación de macros antes de descargar archivos puede ser una ayuda muy eficaz en la lucha contra el malware

Se debe establecer una política para prohibir la introducción de software no autorizado y proteger contra archivos o software de fuentes externas.

Algunos requisitos para abordar la detección de Software malicioso

  • Definir responsabilidades sobre los que tienen la misión específica de realizar las tareas detección de malware y las de los usuarios
  • Realizar las capacitaciones necesarias para que el personal dedicado a la tarea de detección de Software malicioso tenga los conocimientos necesarios
  • Capacitar a los usuarios para que sepan cómo deben actuar cuando reciben una alarma de detección de software malicioso
  • Establecer procedimientos para las tareas de mantenimiento y las situaciones de emergencia
  • Establecer procedimientos de aislamiento en caso de detección y recuperación de cualquier ataque.
  • Incluir en las políticas de seguridad las acciones y procedimientos establecidos en los planes de continuidad del negocio para casos de recuperación ante incidentes

Otros criterios para las políticas de detección de Malware

  • Establecer sistemas de monitoreo de software y los datos de la red.
  • La localización de archivos o parcheo software no aprobados deben investigarse y resolverse como incidentes de seguridad.
  • Los equipos deberían escanearse periódicamente especialmente cuando se va a instalar un nuevo software
  • Los escaneos deberían incluir archivos adjuntos de correo electrónico, descargas y páginas web.
  • La formación continúa a los empleados como herramienta para mantener actualizados a los usuarios de las nuevas amenazas y de cómo responder a ellas.
  • Los empleados deben conocer también cuales son los problemas que puede causar el software malicioso.

Objetivo 3 Respaldo - Copias de Seguridad

Evitar la pérdida de datos mediante la aplicación de una política de copias de seguridad que permita asegurar la disponibilidad e integridad de la información ante incidentes.

Este objetivo incluye un único control:

12.3.1 Copias de seguridad de la información

El proceso de copias de seguridad de la información debería ser definido por una política de copias de seguridad o de respaldo de la información que tenga en cuenta la periodicidad con la que se hacen las copias, esto dependerá de las necesidades de recuperación de cada tipo de información

Otros aspectos a tener en cuenta serian

Alcance de las copias de seguridad

Asegúrese que las copias de seguridad tienen un alcance que cubra todas las necesidades de respaldo de su información:

  • Datos e información sensible
  • Software y aplicaciones
  • Datos de configuración de aplicaciones Sistemas etc.
  • Datos sobre accesos, claves etc.
  • Registros de actividades, eventos, mensajes o alarmas del sistema

Verifique su validez

Comprobar que las copias son válidas es una actividad que no se realiza normalmente en empresas pequeñas y medianas, sin embargo puede resultar embarazoso comprobar después de un desastre que los archivos de copia de seguridad no se restauran convenientemente, por lo que resulta de lo más tranquilizador el realizar una verificación de la validez de las copias de seguridad mediante algún proceso de restauración simulado o en algún equipo de prueba

Ubicaciones Alternativas

No solo es importante realizar las copias de seguridad sino la ubicación donde se encuentran. Es muy aconsejable establecer ubicaciones alternativas al emplazamiento de los datos o aplicaciones para aumentar la seguridad ante posibles impactos de desastres ambientales, accidentes, incendios etc.

Medios de recuperación

Los medios de recuperación son tan importantes como las propias copias de seguridad por lo que deberemos tener en cuenta el mantenimiento en perfecto estado de funcionamiento de los medios que nos permitirán la restauración de las copias cuando las necesitemos

Restauraciones parciales

Los medios de recuperación y el sistema de copias de seguridad deberían permitir restauraciones parciales del sistema dependiendo de las distintas aplicaciones y sistemas de forma que un incidente de corrupción de un sistema o aplicación no obligue a la restauración de otras aplicaciones con el consiguiente impacto.

Mantener registros

Mantenga registros de las copias de seguridad como parte de un cronograma o plan de mantenimiento de copias de seguridad. También es aconsejable mantener un registro de las pruebas de validez de dichas copias.

Nivel de protección

Mantenga el mismo nivel de protección para las copias de seguridad que los requeridos para los datos operativos y cuando sea necesario las copias de seguridad deben estar encriptadas

Finalmente, los planes de continuidad del negocio deben tener en cuenta el tiempo requerido para realizar restauraciones completas del sistema, lo que puede requerir una operación diversa en varios sitios.

Objetivo 4 Registros y supervisión

Cuando todo marcha bien este punto quizás no tenga mucha utilidad, sin embargo ante un incidente en la seguridad de la información, resulta un punto indispensable ya que sino no sabríamos por dónde empezar a investigar. Esta es la principal razón por la que los sistemas de información deben mantener registros que a su vez deben ser monitoreados.

Estamos hablando de trazabilidad de los eventos. Para este objetivo, deben definirse las necesidades de trazabilidad o monitorización de cada sistema de información. De esta forma, podremos aplicar un sistema de registros que nos permitan identificar la autoría y los tipos de las acciones que se han ejecutado en dicho sistema.

Los registros que se determinan como controles sobre los sistemas de información son:

12.4.1 Registro de eventos

En primer lugar parece obvio que deberemos mantener un registro de los eventos pues a la hora de un incidente querremos determinar qué estaba sucediendo mediante los datos de la hora, la fecha del incidente, etc., las personas involucradas, el origen y las causas, etc.

La primera tarea será determinar los distintos eventos a registrar en cada sistema:

  • Intentos de acceso exitosos y fallidos,
  • Desconexiones del sistema
  • Acciones ejecutadas,
  • Alertas por fallos en el sistema
  • Fecha y hora en que se producen los eventos
  • Tiempos de detención
  • Etc.

ASPECTOS LEGALES

Tener un sistema sin un registro de eventos puede ser un grave error ya que en algunos casos puede implicar sanciones por incumplimiento de las normas legales sobre protección de datos personales.

PREVENIR INCIDENTES

Revisar los registros de forma periódica, independientemente de si hay un incidente o no puede ayudarnos a analizar tendencias, detectar potenciales actividades fraudulentas, o detectar el origen de fallos de funcionamiento, antes de que ocurran incidentes importantes.

12.4.2 Protección de la información de registros (logs)

Los registros de eventos deben tener el nivel de protección apropiado para evitar pérdidas, corrupción o cambios no autorizados.

Donde sea posible, el administrador del sistema no debe tener permiso para borrar o desactivar el registro de sus propias actividades.

También se deberían guardar copias de seguridad de los registros de eventos

La detección de intrusiones debería ser administrada fuera del alcance de los administradores de red para cumplir con este requisito

12.4.3 Registros del administrador y operador

Como ya hemos adelantado en el punto anterior, deberemos registrar las actividades no solo de los usuarios sino también de los administradores, teniendo especial cuidado con los que tienen privilegios de administración dado el riesgo que tiene si pueden acceder a los registros y manipularlos o borrarlos.

12.4.4 Sincronización de relojes

Aunque existan otros requisitos de sincronización en el sistema, a la hora de registrar eventos es imprescindible que todos los sistemas de procesamiento estén sincronizados. Para cumplir con este requisito, el proceso de sincronización debe estar documentado con los requisitos necesarios para que esto se cumpla.

Objetivo 5 Control de software en la producción

Desgraciadamente todos tenemos experiencias de incompatibilidades en instalaciones de nuevo software o en actualizaciones de versiones existentes. Esto puede afectar tanto al funcionamiento del propio software o aplicación como al rendimiento de los equipos y afectar de rebote a otros sistemas o aplicaciones

Para evitar estos problemas se establece el siguiente control:

12.5.1 Instalación de software en los sistemas operativos

Es importante mantener procedimientos para cubrir las instalaciones de Software en cualquier dispositivo dentro de una organización. Estos procedimientos deben fijarse en la aplicabilidad de los siguientes controles

  • Probar las nuevas aplicaciones o software en entornos aislados especialmente preparados para pruebas
  • Comprobar las necesidades de instalación (compatibilidad del entorno) antes de su instalación
  • Valorar la necesidad de actualización o instalación
  • Planificar la forma de volver a versiones anteriores en caso de ser necesario
  • Los entornos de desarrollo deben permanecer aislados de los entornos operativos
  • Las instalaciones de software debe ser realizada por usuarios autorizados
  • Establecer procedimientos o herramientas de monitoreo del software para detectar cambios no autorizados
  • Las pruebas posteriores a la implementación deben incluir una supervisión de la red para identificar cualquier tráfico inesperado que pueda exponer errores o suponga empeoramiento de la velocidad de las transmisiones.

Objetivo 6 Gestión de vulnerabilidad técnica

Actualmente todas las aplicaciones software están sujetas a actualizaciones con propósito de mejorar no solo su funcionalidad sino sobre todo la seguridad de las mismas

Este apartado nos indica controles para evitar que las posibles vulnerabilidades del software puedan ser aprovechadas por los atacantes

12.6.1 Gestión de vulnerabilidades técnicas

Ante lo expuesto anteriormente queda claro que no sirve quedarnos de brazos cruzados ante un entorno cada vez más hostil en el mundo de las aplicaciones software.

Es por ello que debemos gestionar nuestras posibles vulnerabilidades identificando nuestras posibles debilidades técnicas mediante

  • La consulta de foros especializados
  • Mantener actualizada la información de fabricantes y proveedores
  • Realizar pruebas de ataques simulados (hacking ético)
  • Escaneos periódicos de vulnerabilidades

Algunos consejos prácticos

Un buen punto de partida para realizar un buen análisis de vulnerabilidades técnicas es tener en cuenta el registro de activos de información.

El inventario de activos de información convenientemente documentado debería ser su guía para evaluar e implementar controles para abordar la vulnerabilidad técnica.

Aquí es donde aplicamos los criterios de cómo están siendo monitoreados los activos de información, cuál es su evaluación de riesgos y los controles que deberemos aplicar para abordar nuestras vulnerabilidades técnicas.

Administrar convenientemente nuestros activos de información puede traernos muchos beneficios ya que nos permite tener la herramienta de decisión para abordar temas como:

  • Como puedo reducir el número de aplicaciones software
  • Qué tipo de aplicaciones cumplen con las reglas y objetivos de la seguridad de la información y están alineadas con los objetivos del negocio y así identificar y trabajar para eliminar aquellas que no las cumplen
  • Establecer entornos de datos cada vez más confiables para reducir en la manera de lo posible las actualizaciones y parcheo del software

En segundo lugar el monitoreo de los sistemas es la herramienta que nos puede brindar valiosa información para tomar decisiones en cuanto a la identificación de vulnerabilidades técnicas

Lo que no se monitorea se desconoce, así que establezca registros y mediaciones (KPI) de los efectos de las actualizaciones de software incluyendo por ejemplo:

  • Cronogramas efectivos para realizar las notificaciones
  • Elementos de medición en aplicaciones no tan comunes como software de control, dispositivos de los empleados, móviles etc.
  • Evalué la eficacia de las actualizaciones antes de generalizarlas a toda la organización mediante sistemas piloto o pruebas en pequeña escala

En tercer lugar establezca una política de control para la instalación de software (esto lo veremos en el siguiente punto)

12.6.2 Restricciones en la instalación de software

Aunque ya se menciona en puntos anteriores la norma quiere insistir en establecer restricciones para la instalación de software por parte de los usuarios.

Ya quedo claro que la instalación de software debe realizarse por personal autorizado y con la capacitación adecuada. Aquí se trata de que además definamos unas reglas concisas para limitar la capacidad de los usuarios finales.

Estas restricciones deben ir enfocadas a identificar expresamente:

  • Qué tipos de instalaciones de software son las permitidas a los usuarios finales (por ejemplo, actualizaciones y parches de seguridad al software existente)
  • Qué tipos de instalaciones se encuentran prohibidas (por ejemplo, software que es sólo para uso personal y software cuyo origen pueda ser potencialmente dañino etc.

Objetivo 7 Consideraciones sobre la auditoría de sistemas de información

Minimizar el impacto de las actividades de auditoría en los sistemas operativos

Algunas auditorias sobre sistemas de información pueden conllevar una intención con los dichos sistemas. Se trata de establecer controles para minimizar este impacto mediante la planificación de actividades de forma que causen la mínima interferencia en sistemas operativos.

12.7.1 Controles de auditoría de sistemas de información

Se trata de auditorías técnicas sobre sistemas, No se refiera este punto a la auditoria de cumplimiento de la norma ISO 27001 sino más bien a las auditorias de los sistemas de información para evaluar cosas como:

  • ¿Los usuarios están trabajando con los privilegios correctos?
  • ¿La infraestructura es estable y confiable?
  • ¿Las infraestructuras cuentan con la suficiente capacidad (memoria, procesamiento, almacenamiento, ancho de banda)?
  • ¿Cómo puede ser mejorado?
  • ¿Las pruebas realizadas son efectivas?
  • ¿Cuán efectivas son las actividades de mantenimiento, monitoreo y gestión?
  • ¿Qué hacen los usuarios del sistema?

En este aspecto deberemos controlar que las auditorias para obtener esta información

1 Cumplan con el alcance planificado.

En la práctica el alcance de las auditorias puede ser demasiado abierto de forma que la auditoría podría convertirse en una enorme tarea que reduce su propio valor, perdiendo un enorme esfuerzo en cosas que son de poca importancia. Delimitar las auditorias es una primera y primordial tarea para no devaluar su significado y para que realmente sean útiles

2 Evaluar y considerar el impacto

Se debe evaluar el impacto o consumo de recursos de auditorías que supongan un consumo de recursos importante dentro de los sistemas. En este caso debe existir un procedimiento por el cual se evite realizar estas tareas que pueden comprometer la capacidad de los sistemas realizándolas en periodos de baja carga de trabajo