Alineando CobiT 4.1, ITIL V3 e ISO 27002 para beneficio del negocio

Como pudieron darse cuenta, las dos últimas entradas fueron sobre ITIL y CobiT respectivamente. Que relación tienen CobiT, ITIL e ISO 27000? La experiencia demuestra que resulta algo complicado implementar un SGSI sin tocar aunque sea tangencialmente a Cobit o ITIL por la gestión de la información que exista en una Organización. Así las cosas, Ud. puede estar implementando su SGSI pudiendo mejorar este sistema mediante la inclusión de indicadores de ITIL, o midiendo el estado de maduración de su SGSI a través de CobiT. Para cerrar este ciclo de CobiT, ITIL e ISO 27000, observemos brevemente que nos ofrece cada una de ellas:

CobiT
Marco de referencia para objetivos de control sobre la información y recursos tecnológicos asociados. Cobit fue creado por ISACA  (Information System Control Standard) la cual es una organización sin ánimo de lucro enfocada en el Gobierno y control de IT. La función principal de CobiT es ayudar a las Organizaciones a mapear sus procesos de acuerdo a las mejores prácticas recopiladas por ISACA. Cobit usualmente es implementado por compañías que realizan auditorías de sistemas de información, ya sea relacionadas con la auditoría financiera o auditoría de TI en general.

ITIL
Marco de referencia para Infraestructura de Tecnologías de Información. ITIL fue creado por la OGC (Office of Government Commerce), y es un marco de referencia para gestionar los diferentes niveles de servicios IT. Aunque ITIL es similar a CobiT en muchos aspectos, CobiT se enfoca en los procesos base y en riesgos, mientras que ITIL se enfoca en los servicios IT.

ISO 27000
Estándar enfocado exclusivamente en la seguridad, lo cual le hace muy diferente a los estándares manejados por CobiT o ITIL. Esta diferencia hace que la ISO 27000 tenga un alcance menor pero más profundo en el tema obviamente de seguridad comparándole con ITIL o CobiT

A continuación, una tabla de comparación de estos tres modelos:

Bien, por que entonces el titulo de esta entrada es Alineando CobiT 4.1, ITIL V3 e ISO 27002 para beneficio del negocio? Existe un excelente texto desarrollado por ITGI y OGC titulado Alineando COBIT® 4.1, ITIL® V3 e ISO/IEC 27002 en beneficio del negocio (ó de la empresa, dependiendo si miran la portada o el encabezado de todas las paginas del libro), que mediante un mapeo realizado a traves de tablas nos permite ver al implementar un control de ISO 27002, que estamos cumpliendo en ITIL y CobiT o en cualquier sentido: desde CobiT ,  ITIL ó ISO 27002 podemos verificar que cumplimos en cualquiera de los otros dos modelos.

Veamos el prefacio de este titulo:

Cada empresa necesita ajustar la utilización de estándares y prácticas a sus requerimientos individuales. En este sentido, los tres estándares/prácticas cubiertos en esta guía pueden desempeñar un papel muy útil, COBIT® e ISO/IEC 27002 para ayudar a definir lo que debería hacerse, e ITIL proporciona el cómo para los aspectos de la gestión de servicios.

La creciente adopción de mejores prácticas de TI se explica porque la industria de TI requiere mejorar la administración de la calidad y la confiabilidad de TI en los negocios y para responder a un creciente número de requerimientos regulatorios y contractuales. Sin embargo, existe el peligro de que las implementaciones de estas mejores prácticas, potencialmente útiles, puedan ser costosas y desenfocadas si son tratadas como guías puramente técnicas. 

Para ser más efectivos, las mejores prácticas deberían ser aplicadas en el contexto del negocio, enfocándose donde su utilización proporcione el mayor beneficio a la organización. La alta dirección, los gerentes, auditores, oficiales de cumplimiento y directores de TI, deberían trabajar en armonía para estar seguros que las mejores prácticas conduzcan a servicios de TI económicos y bien controlados.

Este libro que inicialmente fue lanzado en idioma ingles, ahora ya se encuentra disponible en español en este link: Aligning COBIT 4.1, ITIL V3 and ISO/IEC 27002 for Business Benefit  Espero que aprovechen este texto, ya que para mi fue una herramienta muy valiosa al momento de afrontar mi primera auditoría externa del SGSI. 

ISO 27001 e ISO 27002: Manual del Sistema de Gestión de Seguridad de la Información

Otra duda frecuente al enfrentarse a la documentación de un SGSI, es que incluir en el Manual de Seguridad de Información. Aquí hay varios puntos a tener en cuenta:

Si ya existe un Sistema de Gestión previo, lo ideal es manejar un Sistema de Gestión Integrado que consolide los sistemas existentes quedando bajo un solo modelo por ejemplo calidad y seguridad de la información, o ambiental y seguridad de la información, etc.

Si no existe un manual previo, pues habrá que definir una Norma Cero o Guía de documentación que establezca como documentar todo lo perteneciente al SGSI, y una vez se inicie la documentación, poder entonces desarrollar el Manual de Seguridad de la Información.

En cualquiera de los dos casos, les sugiero manejar la siguiente tabla de contenido para su Manual de Seguridad de la Información:

1. Organización
2. Introducción
3. Manual de Seguridad de la información
3.1 Objetivo
3.2 Alcance del SGSI
3.3 Control de Cambios y Aprobación
4. Marco legal
5. Glosario
6. Política de Seguridad
6.1 Compromiso De La Dirección
6.2 Política de seguridad de la Organización
6.3 Revisión de la Política
6.4 Conformidad Con la Política de Seguridad y los estándares de Control
6.5 Objetivos De La Gestión De Seguridad De Información
7. Normas y políticas del Sistema de Gestión de Seguridad de la Información
7.1 Organización del SGSI
7.2 Gestión de Activos
7.3 Recursos Humanos
7.4 Seguridad Física y Ambiental
7.5 Comunicaciones y Operaciones
7.6 Control de Acceso
7.7 Desarrollo de Software
7.8 Gestión Incidentes
7.9 Continuidad del Negocio
7.10 Cumplimiento
8. Determinación de requerimientos de seguridad de la información
8.1 Identificación de Activos de seguridad de la Información
8.2 Descripción de la metodología de evaluación del riesgo
8.3 Reporte de evaluación del riesgo y Plan de tratamiento del riesgo
8.4 Declaración de Aplicabilidad
9. Roles y Responsabilidades
9.1 Grupo de Sistemas/IT
9.2 Usuario
9.3 Propietario de Información
9.4 Auditoría Interna
10. Autoridades Y Entidades Externas Relevantes Al Negocio
11. Compañías consultoras en SGSI
12. Bibliografía

Espero que esta guía les sirva de utilidad, pues cuando yo inicie mi implementación esta información no estaba pude encontrarla en ningún sitio, y haciendo hincapie en que esta tabla de contenido es las que yo implemente, pudiendo Uds modificarla de acuerdo a las necesidades del SGSI en el que esten trabajando.

ISO 27001 e ISO 27002: Dominio 15 Cumplimiento

Continuando con los Dominios de la ISO 27002 (Numeral 15) o Anexo A de la ISO 27001 (Anexo A15), hoy vamos a revisar el Cumplimiento. Que dicen la ISO 27001 e ISO 27002? Bien, incluye tres objetivos de control:

15.1 CUMPLIMIENTO DE REQUISITOS LEGALES

Objetivo: evitar el incumplimiento de cualquier ley, de obligaciones estatutarias, reglamentarias o contractuales y de cualquier requisito de seguridad. El diseño, el uso, la operación y la gestión de los sistemas de información pueden estar sujetos a requisitos de seguridad estatutarios, reglamentarios y contractuales.

Se debería buscar asesoría sobre los requisitos legales específicos de los asesores jurídicos de la organización o de abogados practicantes calificados. Los requisitos legales varían de un país a otro y pueden variar para la información creada en un país y que se transmite a otro (es decir, el flujo de datos transfronterizo).

15.2 CUMPLIMIENTO DE LAS POLÍTICAS Y LAS NORMAS DE SEGURIDAD Y CUMPLIMIENTO TÉCNICO
Objetivo: asegurar que los sistemas cumplen con las normas y políticas de seguridad de la organización. La seguridad de los sistemas de información se debería revisar a Intervalos regulares.

Dichas revisiones se deberían llevar a cabo frente a las políticas de seguridad apropiadas y se deberían auditar las plataformas técnicas y los sistemas de información para determinar el cumplimiento de las normas aplicables sobre implementación de la seguridad y los controles de seguridad documentados.

15.3 CONSIDERACIONES DE LA AUDITORÍA DE LOS SISTEMAS DE INFORMACIÓN

Objetivo: maximizar la eficacia de los procesos de auditoría de los sistemas de información y minimizar su interferencia.

Deberían existir controles para salvaguardar los sistemas operativos y las herramientas de auditoría durante las auditorias de los sistemas de información y minimizar su interferencia.

Deberían existir controles para salvaguardar los sistemas operativos y las herramientas de auditoría durante las auditorias de los sistemas de información. También se requiere protección para salvaguardar la integridad y evitar el uso inadecuado de las herramientas de auditoría.

La Norma busca que para todos los proyectos desarrollados por la Organización, en el diseño, operación, uso y gestión de los sistemas de información se debe evaluar si deben estar sujetos a obligaciones estatutarias, reglamentarias y contractuales de seguridad. De ser así se debe evitar el incumplimiento a cualquier ley civil o penal, obligaciones estatutarias, reglamentarias o contractuales de cualquier requisito de seguridad. Veamos un poco mas:

Todas las actividades que realicen los funcionarios o proveedores de servicios externos de la Organización, en donde utilicen los activos de información del la Organización deben acogerse a la política de seguridad y de cumplimiento técnico corporativo que le aplique. En la Organización se debe asegurar que los sistemas de información con los que se interactúa cumplen con las normas y políticas de seguridad de la organización.

Para asegurar la protección de los sistemas operativos y las herramientas de auditoría durante las auditorias del sistema se deben establecer los controles respectivos y necesarios.

Ahora profundizando:

1. Cumplimiento de los requisitos legales
Para cada sistema de información en la Organizacion se deben definir, documentar específicamente y mantener actualizados los requisitos estatutarios, reglamentarios y contractuales, se deben definir los controles, medidas y responsabilidades específicos para su cumplimiento.

Para la definición y cumplimiento de los requisitos legales específicos en la Organizacion se debe buscar el soporte de los asesores jurídicos de la organización. Sobre la utilización de software patentado y/o utilización de material en el cual pueden existir derechos de propiedad intelectual en la Organizacion, se deben implementar procedimientos apropiados para el aseguramiento del cumplimiento de los requisitos legales, reglamentarios y contractuales. (Ejemplo: licencias, software legal, etc).

Los registros importantes, confidenciales o sensibles de la Organización se deben proteger contra la pérdida, destrucción y falsificación, por lo tanto se deben guardar de forma segura, para cumplir con los requisitos estatutarios, legales, contractuales y de la organización.

Los funcionarios de la Organización y usuarios de terceras partes deben estar informados que no es permitido otro acceso que no sea el autorizado a los sistemas y servicios de procesamiento de información. Los controles criptográficos o de cifrado que se utilicen en la Organización deben cumplir con todos los acuerdos, leyes y reglamentos pertinentes con el país donde sean aplicados o donde se traslade información cifrada.

2. Cumplimiento de las políticas y las normas de seguridad y cumplimiento técnico

Se debe asegurar el cumplimiento de los sistemas con las políticas y normas de seguridad estipuladas por la Organización. Cada responsable de los procesos en la Organizacion debe garantizar el correcto funcionamiento de todos los procedimientos de seguridad que se encuentren dentro de sus responsabilidades para lograr el cumplimiento con las políticas y normas de seguridad.

Se deben realizar revisiones regulares al menos una por año y/o de acuerdo a la programación de las auditorias internas, a todas las áreas de la Organización y a los propietarios de sistemas de información para asegurar el cumplimiento de las políticas, normas y cualquier otro requisito apropiado de seguridad.

Para determinar el cumplimiento con las normas de implementación de seguridad, los sistemas de información deben ser verificados periódicamente. Una verificación del cumplimiento técnico asegura que los controles y medidas de hardware y software han sido implementados correctamente en los sistemas operativos de la Organización. Este tipo de verificaciones las deben realizar o supervisar únicamente personas competentes y autorizadas.

3. Consideraciones de la auditoría de los sistemas de información
Durante las auditorias del sistema se deben establecer controles para la protección de los sistemas operativos y de las herramientas de auditoría, para maximizar la eficacia de los procesos de auditoría de los sistemas de información y minimizar su interferencia.

Para minimizar el riesgo de interrupciones de los procesos de negocio de la Organización, se deben planificar y acordar detalladamente los requisitos y las actividades de auditoría lo cual implica verificaciones de los sistemas operativos.

Para evitar el uso inadecuado o evitar poner en peligro las herramientas de auditoría de los sistemas de información, éstas deben estar protegidas, deben estar separadas de los sistemas de desarrollo y de producción, no se deben mantener en librerías de cintas o áreas de usuario, salvo que estén debidamente protegidas.

ISO 27001 e ISO 27002: Dominio 14 Gestión de la Continuidad del Negocio

Continuando con los Dominios de la ISO 27002 (Numeral 14) o Anexo A de la ISO 27001 (Anexo A14), hoy vamos a revisar la Gestión de la Continuidad del Negocio. Que dicen la ISO 27001 e ISO 27002? Bien, incluye un objetivo de control:

14.1 ASPECTOS DE SEGURIDAD DE LA INFORMACIÓN EN LA GESTIÓN DE CONTINUIDAD DEL NEGOCIO

Objetivo: Contrarrestar las interrupciones en las actividades del negocio y proteger sus procesos críticos contra los efectos de fallas importantes en los sistemas de información o contra desastres y asegurar su recuperación oportuna.

Se debería implementar un proceso de gestión de la continuidad del negocio para minimizar el impacto y la recuperación por perdida de activos de información en la organización (la cual puede ser el resultado de, por ejemplo, desastres naturales, accidentes, fallas del equipo y acciones deliberadas) hasta un nivel aceptable mediante la combinación de controles preventivos y de recuperación. En este proceso es conveniente identificar los procesos críticos para el negocio e integrar los requisitos de la gestión de la seguridad de la información de la continuidad del negocio con otros requisitos de continuidad relacionados con aspectos tales como operaciones, personal, materiales, transporte e instalaciones.

Las consecuencias de desastres, fallas de seguridad, perdida del servicio y disponibilidad del servicio se deberían someter a un análisis del impacto en el negocio. Se deberían desarrollar e implementar planes de continuidad del negocio para garantizar la restauración oportuna de las operaciones esenciales.

La seguridad de la información debería ser una parte integral de todo el proceso de continuidad del negocio y de otros procesos de gestión en la organización.

La gestión de la continuidad del negocio deberla incluir controles para identificar y reducir los riesgos, además del proceso general de evaluación de riesgos, limitar las consecuencias de los incidentes dañinos y garantizar la disponibilidad de la información requerida para los procesos del negocio.

Como se puede interpretar, la Norma busca que la información de la Organización SIEMPRE este disponible, y cuando no pueda estarlo, su tiempo de no disponibilidad sea lo mas reducido posible para no afectar las operaciones, al cliente, etc. Profundicemos en los requisitos:

Para llevar a cabo la gestión de continuidad del negocio en la Organización se debe definir e implementar un proceso para reducir la interrupción causada por desastres naturales, accidentes y fallos de seguridad por medio de la combinación de controles preventivos y de recuperación.

Para el aseguramiento de la restauración de los servicios y sistemas de procesos manejados en la Organización en plazos requeridos para el aseguramiento de la continuidad del negocio, se deben desarrollar e implementar planes de contingencia, los cuales deben ser probados para que se integren con todos los demás procesos de gestión.

Las consecuencias causadas por desastres naturales, fallos de seguridad y pérdidas de servicio deben ser analizadas. Se deben definir e implementar normas y controles para la identificación y reducción de riesgos, limitar las consecuencias de incidentes dañinas y asegurar la reanudación, a tiempo, de las operaciones esenciales.

Pero que debería incluir el Plan de Continuidad de Negocio?

Se debe seguir una estrategia de recuperación alineada con los objetivos de negocio, formalmente documentada y con procedimientos perfectamente probados para asegurar la restauración de los procesos críticos del negocio, ante el evento de una contingencia.

Esta estrategia debe mantener una estructura unificada para asegurar la consistencia de todos los planes y considerar los requisitos de seguridad de la información de forma consistente. Cada Responsable de los procesos de la Organización con el acompañamiento del área del Sistemas debe diseñar, implementar, probar y mantener su Plan de Continuidad. El plan de continuidad debe considerar los siguientes aspectos:

1. Procedimientos de contingencia. Los cuales describen las acciones a tomar cuando ocurre un incidente que interrumpe las operaciones del negocio, proporcionando mecanismos alternos y temporales para continuar con el procesamiento.
2. Procedimientos de recuperación. Los cuales describen las acciones a seguir para trasladar las actividades del negocio a un centro alterno de recuperación.
3. Procedimientos de retorno. Los cuales describen las acciones a seguir para regresar las operaciones normales a las instalaciones originales.
4. Programación de pruebas. Las cuales describen la periodicidad en que el plan de continuidad debe ser probado.
5. Actualización periódica. El plan debe actualizarse cuando cambios realizados en el ambiente operativo impacten su funcionalidad. Un análisis de impacto al negocio debe ser realizado como mínimo una vez al año, con el objeto de determinar la necesidad de la disponibilidad de la información en el grado y escala de tiempo requeridos después de una interrupción de las funciones críticas de la Organización.
6. Consideraciones de seguridad. Es importante que el plan sea diseñado para mantener los controles de seguridad establecidos por la Organización, aún cuando se opere en modalidad de contingencia. Es responsabilidad de la Coordinación de Seguridad de la Información asegurar que estas consideraciones sean efectivamente contempladas en el plan.
7. El Plan de Continuidad debe estar alineado con los riesgos identificados que puedan causar interrupción al servicio. Para este caso, se debe tener en cuenta las posibles consecuencias para la seguridad de la información.

Cuando se realicen pruebas, simulacros o se tengan contingencias reales, los resultados y sugerencias deben ser entregadas a los responsables de la información quienes deben actualizar sus planes y mantenerlos al día conforme los riesgos de disponibilidad lo dictaminen. Al menos cada seis meses, se deben realizar ejercicios regulares y diagramados de recuperación del sistema para probar la efectividad del plan de continuidad del negocio.

El objetivo de realizar pruebas de los planes de continuidad, es probar que el plan se encuentre debidamente actualizado, que los procedimientos funcionan adecuadamente y que se obtiene la recuperación requerida en el tiempo programado.

Como se puede observar, idealmente un Plan de Continuidad de Negocios contiene procedimientos de contingencia, de recuperación, de retorno, de pruebas, debe ser actualizado con una periodicidad preestablecido cuando la situación lo amerite, y muy importante, estar alineado con los riesgos que se haya identificado cuya materialización u ocurrencia desemboque en interrupciones de servicio.

ISO 27001 e ISO 27002: Dominio 13 Gestión de los incidentes de la seguridad de la información

Continuando con los Dominios de la ISO 27002 (Numeral 13) o Anexo A de la ISO 27001 (Anexo A13), hoy vamos a revisar la Gestión de los incidentes de la seguridad de la información. Que dicen la ISO 27001 e ISO 27002? Bien, incluyen dos objetivos de control:

13.1 reporte sobre los eventos y las debilidades de la seguridad de la información

Objetivo: asegurar que los eventos y las debilidades de la seguridad de la información asociados con los sistemas de información se comunican de forma tal que permiten tomar las acciones correctivas oportunamente.

Es conveniente establecer el reporte formal del evento y los procedimientos de escalada.

Todos los empleados, contratistas y usuarios de tercera parte deberían tener conciencia sobre los procedimientos para el reporte de los diferentes tipos de evento y las debilidades que puedan tener Impacto en la seguridad de los activos de la organización. Se les debería exigir que reporten todos los eventos de seguridad de la información y las debilidades tan pronto sea posible al punto de contacto designado.

13.2 Gestión De Los Incidentes Y Las Mejoras En La Seguridad De La Información

Objetivo: asegurar que se aplica un enfoque consistente y eficaz para la gestión de los incidentes de seguridad de la información.

Es conveniente establecer las responsabilidades y los procedimientos para manejar los eventos y debilidades de la seguridad de la información de manera eficaz una vez se han reportado. Se debería aplicar un proceso de mejora continua a la respuesta para monitorear, evaluar y gestionar en su totalidad los incidentes de seguridad de la información.

Cuando se requiere evidencia, ésta se debería recolectar para garantizar el cumplimiento de los requisitos legales.

Interpretando los requisitos de la norma, podemos encontrar lo siguiente:

La gestión de los incidentes de seguridad se ha convertido en un componente importante dentro de los programas de tecnología de información y seguridad de la información.

Las acciones preventivas y correctivas que se generan una vez se realizan análisis de riesgos y auditorias del SGSI pueden disminuir el número de incidentes que sean susceptibles de presentarse, pero no todos pueden ser prevenidos.

Deben definirse lineamientos para la gestión de varios tipos de incidentes específicos:

• Negación de Servicio (DoS – Denial of service):

Los ataques de denegación de servicio se refieren al uso específico de ciertas herramientas por parte de intrusos con el fin de causar que las redes y/o sistemas dejen de operar apropiadamente.

Los ataques de denegación de servicio distribuido son aquellos realizados por un grupo de atacantes localizados en diferentes sitios geográficos en donde simultáneos ataques son lanzados hacia el sistema víctima. Debido a ello, es difícil localizar las fuentes del ataque.

• Ataques de Código malicioso:

Código malicioso pueden ser programas como virus, gusanos, troyanos, spyware o scripts utilizados por intrusos para lograr acceso privilegiado, capturar contraseñas o información confidencial. Los ataques de código malicioso son a veces difíciles de detectar debido a que ciertos virus o gusanos son diseñados para modificar su propia firma después de lograr infiltrar un sistema, algunos incluso son capaces de ocultar logs de auditoría para ocultar las actividades no autorizadas.

• Acceso no autorizado:

El acceso no autorizado va desde el uso no autorizado de credenciales hasta la modificación o cambio de archivos y directorios almacenados en un sistema o medio de almacenamiento. Esto adicionalmente puede lograr acceso a otros sistemas a través de programas o dispositivos de “sniffing” que pueden ser instalados para capturar información confidencial que este moviéndose por la red.

• Usos no apropiados:

Ocurren cuando un usuario lleva a cabo acciones que violan las políticas de uso aceptable de los recursos computacionales.

Estos lineamientos deben incluir la definición de procedimientos para la preparación frente a incidentes, identificación, análisis, contención, eliminación y recuperación de incidentes.

Ya teniendo como base una identificación de posibles incidentes que se puedan presentar en la Organización, como seria entonces la gestión de incidentes de seguridad de la información? Veamos:

Un incidente de seguridad de la información se debe entender como un evento relevante que atenta contra la seguridad de los sistemas de cómputo, redes de computadores u otro recurso informático o no informático de la organización; generalmente interrumpe su procedimiento de operación normal.

Los tipos de incidentes de seguridad de la información pueden estar relacionados con cualquier tipo de evento que pueda considerarse que atenta contra la seguridad de los componentes de la infraestructura de tecnología informática y telecomunicaciones u otros activos de la Organización.

1. Detección y reporte de incidentes

Deben existir mecanismos que permitan la detección y el registro de eventos informáticos de forma que sea posible realizar el análisis de los mismos por medio de una evidencia de su ocurrencia.

Los incidentes pueden ser detectados y registrados a través de los siguientes medios:

a) Equipos IDSs, IPSs de red e IDSs basados en Host (HIDS).

b) Alertas generadas por medio de software antivirus, antispyware o antyspam.

c) Software de verificación de integridad de archivos.

d) Servicios externos de monitoreo contratados por la Organización.

e) Logs de sistemas operativos, servicios de red y aplicaciones como sitios Web, entre otras.

f) Logs de los dispositivos de red (router, switch, access point, etc).

g) Información de vulnerabilidades conocidas sobre diferentes tecnologías.

h) Información de incidentes ocurridos en otras Organizaciones.

i) Personas dentro de la organización (usuarios de los servicios informáticos, administradores de red, administradores de sistemas de información, etc.) que hacen uso del servicio de soporte de sistemas y/o tecnologia.

j) Personas de otras organizaciones que detectan vulnerabilidades en diferentes servicios y notifican a la Organización.

Todos los incidentes de seguridad deben ser reportados en el menor tiempo posible, para acelerar la detección, restauración y reparación de cualquier daño causado, y para facilitar la obtención de cualquier evidencia asociada.

Todos los funcionarios involucrados con la Organización, deben ser conscientes y estar alertas a que la evidencia relacionada con incidentes de seguridad de la información debe ser adecuada y formalmente registrada, retenida y entregada al Administrador de Seguridad de la información, utilizando los medios que estén disponibles para tal fin.

2. Preparación ante Incidentes

Según la complejidad de los incidentes se deben asignar prioridades de atención a éstos. Estas prioridades están clasificadas de la siguiente manera:

a) Incidentes Críticos:

• Estos incidentes pueden afectar la integridad o la confidencialidad de la información, lo cual tiene como resultado la pérdida directa del negocio y/o la reputación.
• El problema y/o incidente requiere solución inmediata, ya que este causa la completa pérdida de un servicio o la interrupción de las actividades laborales.
• Se genera un impacto crítico en el cliente.
• Se genera un impacto crítico en aplicaciones o procesos de negocio
• Afecta una comunidad de usuarios o a un usuario de servicios informáticos de alto rango.

b) Incidentes Severos:

• Estos incidentes afectan típicamente la disponibilidad de la información, pero no la integridad de la misma.
• El servicio informático, sistema de información o aplicación opera con problemas críticos.
• El servicio informático, sistema de información o aplicación no está operativo, pero no requiere solución inmediata.
• El impacto del negocio no es crítico.

c) Incidentes Normales:

• Estos incidentes pueden afectar la confidencialidad, integridad o disponibilidad de la información, sin embargo no existe pérdida alguna.
• El servicio informático, sistema de información o aplicación opera con funcionalidades limitadas.
• El servicio informático, sistema de información o aplicación no está operativo, pero existen alternativas paralelas y están disponibles.
• No se ven afectados servicios informáticos importantes para el negocio.

d) Incidentes Menores (no afectan la seguridad de la información ni de telecomunicaciones):

Se acuerda y programa con el usuario de servicios informáticos la atención, para una fecha determinada. En este tipo se incluyen:

• Actualizaciones de hardware y software.
• Nuevas instalaciones de PC, hardware y software.
• Movimientos de oficinas o reasignación de máquinas.
• Reporte y registro de fallas de software.

Con base en los requerimientos contractuales y para darle peso y solución inmediata a los incidentes reportados, se debe dar respuesta en máximo una hora al usuario sobre el tema o inconveniente reportado, con la fecha estimada inicial que se de de acuerdo a la valoración que se realice.

Se deben preparar, mantener y probar regularmente planes para asegurar que el daño producido por posibles ataques externos puede ser minimizado y que la restauración tendrá lugar lo más pronto posible.

3. Análisis de Incidentes

Los incidentes de seguridad deberán ser apropiadamente investigados por personal adecuadamente entrenado y calificado. Ningún incidente se dará por resuelto sin que sea cerrado por el responsable de su manejo, dependiendo de la categoría del incidente.

En caso de que el incidente se relacione con un sistema tecnológico específico, nunca se debe apagar o reiniciar el sistema comprometido de manera inmediata, ya que esto puede llevar a la pérdida de información o evidencia necesaria para una investigación forense posterior.

4. Contención

Se debe limitar la posibilidad de que el daño causado por el incidente se extienda. Para ello se debe evaluar si se aíslan los componentes comprometidos del resto de componentes de la red, teniendo en cuenta que esto puede afectar o interrumpir la operación normal en caso de que el sistema comprometido sea crítico o muchos sistemas sean afectados por el problema como sucede en una epidemia de virus.

En caso de que la atención de cualquier incidente implique riesgo para la seguridad de las personas involucradas en su atención, se deberá informar a la gerencia de la Organización, y no se realizará intervención hasta que no se realice el aseguramiento de las condiciones del sitio a intervenir.

5. Eliminación

Después de lograr la contención, se debe iniciar una etapa de investigación que permita establecer la causa del incidente. Si son incidentes relacionados con tecnología, es necesario realizar un análisis detallado de los logs, en diferentes dispositivos (firewalls, routers, logs de sistema/aplicaciones). Para ello se deben utilizar herramientas diferentes a aquellas existentes en el sistema comprometido.

Después de la investigación, el sistema afectado debe ser reinstalado.

6. Recuperación

• Se debe validar la ejecución de las tareas de eliminación.
• Se debe restaurar el componente afectado desde un backup limpio.
• Se debe monitorear el componente para determinar si su funcionamiento es normal, previo a la puesta en producción.
• Se debe implementar un monitoreo a nivel de red para detectar intentos posteriores de ataque.

7. Seguimiento

Se debe crear una base de datos de incidentes en la cual se consignen los reportes de incidentes y la solución dada a los mismos, que sirva en un futuro como primera alternativa de consulta en la resolución de incidentes informáticos.

La información de registro de administración de incidentes debe contener aspectos como: descripción de la secuencia exacta de eventos, forma de descubrimiento del incidente, acción preventiva utilizada, análisis que determine que los pasos de recuperación son suficientes y recomendaciones adicionales que deban ser consideradas.

La base de datos de incidentes que se generen al interior de la Organización será revisada con intervalos no mayores a un año para verificar que los mismos no se repitan o si se han modificado las circunstancias, desarrollar una nueva medida de control que minimice la posibilidad e impacto de este incidente en caso de que se diera la posibilidad de volver a presentarse.

8. Evidencias de Incidentes

Todo incidente de seguridad que se reporte debe venir acompañado de algún tipo de evidencia que respalde el reporte que se realice. Estas evidencias resultan fundamentales en situaciones como la aplicación del proceso disciplinario desarrollado para el SGSI

Cuando una acción de seguimiento contra una persona u organización después de un incidente de seguridad de la información implica acciones legales (civiles o penales), la evidencia se debe recolectar, retener y presentar para cumplir con las reglas para la evidencia establecidas en la jurisdicción pertinente.

Como se puede apreciar, la gestión de incidentes es un insumo de increíble valor para el SGSI, pues contribuye a robustecer cualquier areá que se vea afectada con un incidente, de alli la importancia de que este Dominio este aplicado en la Organización con una estructura muy fuerte de trabajo, respuesta y gestión de incidentes.

ISO 27001 e ISO 27002: Dominio 12 Adquisición, desarrollo y mantenimiento de sistemas de información.

Continuando con los Dominios de la ISO 27002 (Numeral 12) o Anexo A de la ISO 27001 (Anexo A12), hoy vamos a revisar la Adquisición, desarrollo y mantenimiento de sistemas de información. Que dicen la ISO 27001 e ISO 27002? Bien, incluyen seis objetivos de control:

12.1 Requisitos de seguridad de los sistemas de información
Objetivo: garantizar que la seguridad es parte integral de los sistemas de información.

Los sistemas de información incluyen sistemas operativos, infraestructura, aplicaciones del negocio, productos de vitrina, servicios y aplicaciones desarrolladas para usuarios. El diseño y la implementación del sistema de información que da soporte a los procesos del negocio pueden ser cruciales para la seguridad. Se deberían identificar y acordar los requisitos de seguridad antes del desarrollo y/o la implementación de los sistemas de información.

Todos los requisitos de seguridad se deberían identificar en la fase de requisitos de un proyecto y se deberían justificar, acordar y documentar como parte de todo el caso de negocio para un sistema de Información.

12.2 Procesamiento Correcto en las Aplicaciones
Objetivo: evitar errores. pérdidas, modificaciones no autorizadas o uso inadecuado de la información en las aplicaciones.

Se deberían diseñar controles apropiados en las aplicaciones, incluyendo las aplicaciones desarrolladas por el usuario para garantizar el procesamiento correcto. Estos controles deberían incluir la validación de los datos de entrada, del procesamiento interno y de los datos de salida.

Se pueden necesitar controles adicionales para los sistemas que procesan o tienen impacto en la información sensible, de valor o critica. Dichos controles se deberían determinar con base en los requisitos de seguridad y en la evaluación de riesgos.

12.3 Controles Criptograficos
Objetivo: proteger la confidencialidad, autenticidad o integridad de la información, por medios criptográficos.

Se debería desarrollar una política sobre el uso de los controles criptográficos y establecer una gestión de claves para dar soporte al empleo de técnicas criptográficas.

12.4 Seguridad de los archivos de sistema
Objetivo: garantizar la seguridad de los archivos del sistema.

Los accesos a los archivos del sistema y al código fuente del programa deberían estar protegidos, y los proyectos de tecnología de la información y las actividades de soporte se deberían efectuar de forma segura. Se debería tener cuidado para evitar la exposición de datos sensibles en los entornos de prueba.

12.5 Seguridad en los procesos de desarrollo y soporte.
Objetivo: mantener la seguridad del software y de la información dél sistema de aplicaciones.

Los entornos de soporte y de desarrollo deberían estar estrictamente controlados.

Los directores responsables de los sistemas de aplicación también deberían ser responsables de la seguridad del entorno del proyecto o del soporte. Ellos deberian garantizar que todos los cambios propuestos en el sistema se revisan para comprobar que no ponen en peligro la seguridad del sistema ni del entorno operativo.

12.6 Gestión de la vulnerabilidad técnica.
Objetivo: reducir los riesgos resultantes de la explotación de las vulnerabilidades técnicas publicadas.

La gestión de la vulnerabilidad técnica se debería implementar de forma eficaz, sistemática y repetible con toma de mediciones para confirmar su eficacia. Estas consideraciones deberían incluir a los sistemas operativos y otras aplicaciones en uso.


Sintetizando, este es el objetivo que persigue la Norma con este Dominio

Todos los sistemas de procesamiento de información, infraestructura, desarrollos, aplicaciones, archivos, procesos de desarrollo y mantenimiento de sistemas de información de la Organizacion deben ser controlados y tener una adecuada seguridad.

Profundizando en los requerimientos de la Norma:

12.1. Requisitos de seguridad de los sistemas
Los sistemas de información de la Organización, que incluyen la infraestructura, aplicaciones de negocio y aplicaciones desarrolladas por los usuarios deben tener incorporados los controles de seguridad correspondientes.

Se deben identificar y acordar los requerimientos de seguridad que deben contener los sistemas de información de la Organización antes de su desarrollo e implementación. Los requerimientos de seguridad para el desarrollo de los sistemas de información deben quedar documentados como parte del proceso de negocio del proyecto de implementación de sistemas de información.

12.2. Seguridad de las aplicaciones del sistema
Para las aplicaciones y sistemas de información de la Organización se deben diseñar e implementar medidas de control de seguridad y registros de auditoría o de actividades correspondientes a cada aplicación. En el diseño de los controles se deben incluir las validaciones de los datos de entrada, procesamiento interno y datos de salida que maneja la aplicación.

12.3. Controles criptográficos
Toda la información confidencial, sensible o en riego de la Organización debe estar protegida por sistemas y técnicas criptográficas en caso de que otras medidas y controles no le puedan proporcionar la protección apropiada y necesaria para su seguridad.

12.4. Seguridad de los archivos del sistema
Todos los accesos otorgados a los archivos de los sistemas de la Organización deben estar controlados, para asegurar que las actividades de soporte y proyectos de Tecnología de Información son llevados a cabo de forma segura.

12.5. Seguridad en los procesos de desarrollo y soporte
Se deben establecer normas para el control de los entornos del proyecto y procesos de desarrollo y soporte en el mantenimiento de la seguridad del software y de la información manejada por las aplicaciones de los sistemas de la Organización. Cada cambio propuesto para los diferentes sistemas de información debe ser revisado para asegurar que no afecta la seguridad del mismo o la del sistema operativo.

12.6. Gestión de la vulnerabilidad técnica
Se deben establecer normas y controles para reducir los riesgos resultantes de la explotación de las vulnerabilidades técnicas publicadas.

Este Dominio busca asegurar todos la infraestructura que soporta la información de la Organización, proporcionándoles controles adecuados para proteger toda la información de propiedad de la Organización.

ISO 27001 e ISO 27002: Dominio 11 - Control del Acceso

Continuando con los Dominios de la ISO 27002 (Numeral 11) o Anexo A de la ISO 27001 (Anexo A11), hoy vamos a revisar las Comunicaciones y Operaciones. Que dicen la ISO 27001 e ISO 27002? Bien, incluyen siete objetivos de control:

11.1 Requisitos del negocio para el control de acceso

Objetivo: controlar el acceso a la información.
El acceso a la Información, a los servicios de procesamiento de información y a los procesos del negocio se debería controlar con base en los requisitos de seguridad y del negocio.
Las reglas para el control del acceso deberían tener en cuenta las políticas de distribución y autorización de la información.


11.2 Gestión del acceso de usuarios
Objetivo: asegurar el acceso de usuarios autorizados y evitar el acceso de usuarios no autorizados a los sistemas de información.


Se deberían establecer procedimientos formales para controlar la asignación de los derechos de acceso a los sistemas y servicios de información.


Los procedimientos deberían comprender todas las fases del ciclo de vida del acceso del usuario, desde el registro inicial de los usuarios nuevos hasta la cancelación final del registro de usuarios que ya no requieren acceso a los servicios y sistemas de información. Se debería poner atención especial, según el caso, a la necesidad de controlar la asignación de derechos de acceso privilegiado que permiten a los usuarios anular los controles del sistema.


11.3 Responsabilidades de los usuarios
Objetivo: evitar el acceso de usuarios no autorizados, el robo o la puesta en peligro de la información y de los servicios de procesamiento de Información.
La cooperación de los usuarios autorizados es esencial para la eficacia de la seguridad.


Se deberla concientizar a los usuarios sobre sus responsabilidades por el mantenimiento de controles de acceso eficaces, en particular con relación al uso de contraseñas y a la seguridad del equipo del usuario.


Es recomendable implementar una política de escritorio y pantalla despejados para reducir el riesgo de acceso no autorizado o daño de reportes, medios y servicios de procesamiento de Información.


11.4 Control de Acceso a las Redes
Objetivo: evitar el acceso no autorizado a los servicios en red.
Es recomendable controlar el acceso a los servicios en red, tanto internos como externos.
El acceso de los usuarios a las redes y a los servicios de red no debería comprometer la seguridad de los servicios de red garantizando que:

1. existen interfases apropiadas entre la red de la organización y las redes que pertenecen a otras organizaciones. y las redes públicas:
2. se aplican mecanismos adecuados de autenticación para los usuarios y los equipos.
3. se exige control de acceso de los usuarios a los servicios de información.

11.5 Control de Acceso al Sistema Operativo
Objetivo: evitar el acceso no autorizado a los sistemas operativos


Se recomienda utilizar medios de seguridad para restringir el acceso de usuarios no autorizados a los sistemas operativos. Tales medios deberían tener la capacidad para:

1. autenticar usuarios autorizados, de acuerdo con una politica definida de control de acceso;
2. registrar intentos exitosos y fallidos de autenticación del sistema;
3. registrar el uso de privilegios especiales del sistema;
4. emitir alarmas cuando se violan las políticas de seguridad del sistema;
5. suministrar medios adecuados para la autenticación:
6. cuando sea apropiado, restringir el tiempo de conexión de los usuarios.

11.6 Control de Acceso a las aplicaciones y a la información
Objetivo: evitar el acceso no autorizado a la información contenida en los sistemas de aplicación.


Se deberían usar medios de seguridad para restringir el acceso a los sistemas de aplicación y dentro de ellos.
El acceso lógico al software de aplicación y a la información se debería restringir a usuarios autorizados.
Los sistemas de aplicación deberían:

1. controlar el acceso de usuarios a la información y a las funciones del sistema de aplicación, de acuerdo con una política definida de control de acceso;
2. suministrar protección contra acceso no autorizado por una utilidad, el software del sistema operativo y software malicioso que pueda anular o desviar los controles del sistema o de la aplicación:
3. no poner en peligro otros sistemas con Jos que se comparten los recursos de información

11.7 Computación Móvil y Trabajo Remoto
Objetivo: garantizar la seguridad de la información cuando se utilizan dispositivos de computación móviles y de trabajo remoto.


La protección necesaria debería estar acorde con los riesgos que originan estas· formas específicas de trabajo. Cuando se usa la computación móvil, se deberían tener en cuenta los riesgos de trabajar en un entorno sin protección y aplicar la protección adecuada. En el caso del trabajo remoto, la organización deberia aplicar protección en el sitio del trabajo remoto y garantizar que se han establecido las disposiciones adecuadas para esta forma de trabajo.

Ahora vamos a profundizar en los requisitos de la Norma con este Dominio:

1. Administración Accesos usuarios:
Se debe definir, establecer, documentar y revisar mensualmente la política de control de acceso con base en los requisitos del negocio de la Organización y de la seguridad para el acceso a los activos y sistemas de información. En esta política deben establecerse las reglas y derechos de cada usuario o grupo de usuarios.


Todos los usuarios y proveedores de servicios de la Organización deben estar informados de los controles que deben seguir, según la política de control de acceso establecida, a los diferentes sistemas de información y activos con los que interactúan en la Organización.


Se deben establecer procedimientos para controlar la asignación de los derechos de acceso a los sistemas y servicios de la Organización, los cuales deben abarcar las etapas del ciclo de vida del acceso de los usuarios, desde el registro inicial de nuevos usuarios hasta su eliminación o desactivación cuando ya no sea requerido dicho acceso a los sistemas de información y servicios de la Organización.

Para los usuarios que tengan acciones privilegiadas en los sistemas y servicios de información, se deben definir y establecer derechos con acceso privilegiado que permita a estos usuarios evitar controles del sistema o ingresar a información y servicios de administración de más alto perfil.

1.1 Registro de usuarios
Para el registro y cancelación de usuarios para acceder a los diferentes sistemas y servicios de información multiusuarios de la Organización debe definirse y establecerse un procedimiento de registro y desactivación de usuarios, el cual debe incluir:

• Identificador único para cada usuario.
• Comprobación de la autorización del usuario por el propietario del servicio para utilizar el sistema o servicio de información.
• Verificación del nivel ce acceso asignado.
• Entrega a usuario de relación escrita de sus derechos de acceso.
• Mantenimiento de un registro formalizado.
• Eliminación inmediata de autorizaciones de acceso a usuarios que dejan la organización.

1.2. Administración de privilegios
La asignación y uso de privilegios en controles de acceso a los sistemas y servicios de información de la Organización deben estar restringidos y controlados.

1.3. Administración de contraseñas para usuario
La asignación de contraseñas debe estar controlada mediante un proceso de gestión formal.
Las contraseñas deben estar almacenadas en un sistema informático protegido mediante tecnologías diferentes a las utilizadas para la identificación y autenticación de usuarios.

1.4. Revisión de los derechos de acceso de los usuarios
Se debe establecer un proceso formal de revisión mensual de los derechos de acceso de los usuarios, para mantener un control efectivo del acceso a datos y servicios de información de la organización.

2. Responsabilidades de los usuarios
Los empleados de la Organización deben estar conscientes de las responsabilidades que tiene a cada uno con relación al mantenimiento de la eficacia de las medidas de control de acceso a los sistemas y servicios de información de la Organización. Cada usuario debe tener en cuenta las buenas prácticas de seguridad de selección y uso de sus contraseñas.

Los usuarios y proveedores de servicio de la Organización deben garantizar que los equipos informáticos desatendidos estén debidamente protegidos. Para esto deben tener conocimiento de los requisitos de seguridad y de los procedimientos para la protección de los equipos desatendidos, así como de las responsabilidades que ellos tienen asignadas para la implementación de dicha protección.


El usuario es orientado en este aspecto y existen consecuencias definidas por incumplimiento que entran aplicarse en el momento de la investigación del incidente presentado.

Se debe adoptar una política de escritorio despejado para reportes y medios de almacenamiento removibles y política de pantalla despejada para los servicios de procesamiento de información.

3. Control del Acceso de los Usuarios a red corporativa
El administrador del centro de cómputo principal de la Organización debe asegurar que los accesos a las redes y sus servicios no comprometan la seguridad de la infraestructura ubicada en esa locación y los aspectos relacionados con ella.


Los usuarios de la Organización únicamente deben tener permiso de acceso directo a las aplicaciones y bases de datos, para cuyo uso están específicamente autorizados. Este control es importante aplicarlo en conexiones a aplicaciones sensible, críticas o utilizadas por usuarios que se encuentren conectados desde lugares de alto riesgo.

Todos los accesos de los usuarios remotos a sistemas y aplicaciones de información de la Organización deben estar controlados por medio de autenticación.

Se debe seleccionar un método de autenticación que será utilizado por la Organización, por medio de una evaluación de riesgos para determinar el nivel de protección que se requiera.

Todas las conexiones remotas que se realicen a sistemas de información de la Organización deben ser autenticadas. Un medio para autenticar conexiones de equipos y ubicaciones específicas es la identificación automática de los equipos a la red.

Los puertos empleados para diagnóstico remoto y configuración deben estar controlados de forma segura, deben estar protegidos a través de un mecanismo de seguridad adecuado y un procedimiento para asegurar que los accesos lógicos y físicos a estos son autorizados por el director del servicio informático y el personal de mantenimiento de hardware y software que solicita el acceso.


En las redes de la Organización se deben separar los grupos de servicios de información, usuarios y sistemas de información, para evitar accesos no autorizados a los sistemas actuales de información que se encuentran conectados a las redes. Los criterios que se utilicen para realizar la separación de las redes en dominios debe tener en cuenta la política de control de accesos.

Se debe restringir la capacidad de los usuarios y aplicar controles para conectarse a la red dentro de las redes compartidas de la Organización según la política de control de acceso.

Se deben aplicar controles de enrutamiento para el aseguramiento de las conexiones entre computadores y flujos de información para asegurar que no se incumpla la política de control de acceso a las aplicaciones.


Cada uno de los usuarios de la Organización es responsable de usar de forma adecuada los recursos de red y de seguir los procedimientos definidos para accesar a cada uno de los que tenga disponibles para realizar sus labores.

4. Control de acceso al sistema operativo
Todo acceso a los sistemas operativos de la Organización debe estar controlado por registros de inicio seguro. Es importante tener en cuenta la identificación automática de terminales para la autenticación de conexiones a sitios específicos y a equipos portátiles. Se debe definir un procedimiento para la conexión de los usuarios al sistema informático el cual minimice la posibilidad de accesos no autorizados.

Los procesos de conexión empleados deben mostrar el mínimo de información posible sobre el sistema, para no facilitar ayuda innecesaria a usuarios no autorizados. Los mecanismos seguros de "logon" se encuentran documentados en los manuales de usuario de las diferentes aplicaciones.



Se debe limitar y mantener controlado el uso de programas utilitarios del sistema, los cuales sean capaces de eludir medidas de control del sistema o de las aplicaciones. Para las terminales utilizadas por la Organización se debe definir un período de tiempo de inactividad.

Las terminales inactivas en sitios de alto riesgo, en áreas públicas o no cubiertas por el sistema de seguridad de la Organización deben ser desactivadas después de que se cumpla el periodo de tiempo de inactividad previamente definido, para impedir el acceso a estas por usuarios no autorizados.

El dispositivo que realiza la desactivación debe borrar la pantalla y cerrar las aplicaciones y sesiones de conexión a red después de cumplido el periodo de inactividad. Para reducir accesos no autorizados a terminales que manejan aplicaciones de alto riesgo, se deben implementar restricciones en los tiempos de conexión, se debe limitar el periodo de tiempo en el cual se aceptan conexiones desde una terminal.

5. Control de acceso a las aplicaciones
El acceso lógico al software, a la información y a las funciones del sistema de aplicación de la Organización debe estar restringido únicamente para usuarios autorizados, de acuerdo con la política de control de acceso definida. Se deben definir controles de acceso únicamente para los usuarios propietarios de la información, incluso a personal autorizado o a grupos específicos de usuarios.

Se deben identificar los sistemas sensibles de la Organización para darles un tratamiento especial, por lo tanto éstos deben tener un entorno informático dedicado o aislado.

6. Seguridad En Computación Móvil Y Teletrabajo

Se debe aplicar la protección adecuada y se deben considerar los riesgos de trabajar en un entrono desprotegido cuando se utiliza la computación móvil.


Se debe implementar la protección requerida en el lugar de trabajo remoto y asegurar que existen acuerdos adecuados para estos tipos de trabajo.

6.1. Computación Móvil
Cuando se requiera en la Organización de la utilización de dispositivos de computación móvil, como portátiles, agendas, calculadoras y teléfonos móviles, se debe asegurar que la información no se vea comprometida, se debe establecer una política que tenga presente los riesgos de trabajar con dispositivos de computación y comunicaciones móviles, especialmente en entornos desprotegidos.

En lugares públicos o áreas desprotegidas que estén fuera del alcance de seguridad de la organización, se debe tener especial cuidado cuando se utilicen dispositivos móviles, se deben instalar en estos dispositivos una protección adecuada para evitar el acceso no autorizado a la divulgación de la información almacenada y procesada por éstos.


Los dispositivos de computación móvil deben estar protegidos físicamente contra robo.


6.2. Trabajo remoto
Cuando se requiera trabajar de manera remota para la Organización, es decir, fuera de las instalaciones de la organización, se debe proteger adecuadamente el lugar de trabajo remoto contra: robo del equipo o información, distribución no autorizada de información de la Organización, accesos remotos no autorizados a los sistemas internos o mal uso de dispositivos.

Se deben implementar controles y planes operativos para las actividades de trabajo remoto sobre el centro de cómputo principal de la Organización. Se deben tener en cuenta los siguientes controles:

• Aprovisionamiento del equipo o mobiliario adecuados para las actividades de trabajo remoto.
• Definición del trabajo permitido, horas de trabajo, clasificación de la información que puede ser utilizada y sistemas y servicios internos.
• Suministro de equipo de comunicación adecuado.
• Seguridad física.
• Proporcionar soporte y mantenimiento para hardware y software.
• Auditoría y seguimiento de respaldo.

Este Dominio tiene como propósito proteger todas las formas de acceso a la información sensible de la Organización, no solo protegiendo su hardware y software, sino también los recursos humanos involucrados con su manejo.