ISO/CEI 27001

ISO 27001 – Anexo A.12: Seguridad de las operaciones

Vea cómo puede lograr ISO 27001 más rápido con ISMS.online.

Verlo en acción
Por Max Edwards | Actualizado el 14 de diciembre de 2023

Tenga en cuenta que a partir de octubre de 2022, la norma ISO 27001:2013 fue revisada y ahora se conoce como ISO 27001:2022. Consulte los controles completos revisados ​​del Anexo A de ISO 27001 para ver la información más actualizada.

Ver controles revisados ​​del Anexo A.

Saltar al tema


¿Cuál es el objetivo del Anexo A.12.1?

El Anexo A.12.1 trata sobre Procedimientos Operativos y Responsabilidades. El objetivo de esta área del Anexo A es garantizar el funcionamiento correcto y seguro de las instalaciones de procesamiento de información. Es una parte importante del sistema de gestión de seguridad de la información (SGSI), especialmente si desea obtener la certificación ISO 27001. Ahora comprendamos esos requisitos y lo que significan con un poco más de profundidad.

A.12.1.1 Procedimientos operativos documentados

Los procedimientos operativos deben documentarse y luego ponerse a disposición de todos los usuarios que los necesiten. Los procedimientos operativos documentados ayudan a garantizar el funcionamiento coherente y eficaz de los sistemas para el personal nuevo o los recursos cambiantes y, a menudo, pueden ser fundamentales para la recuperación ante desastres, la continuidad del negocio y cuando la disponibilidad del personal se ve comprometida. Cuando los sistemas de información están "basados ​​en la nube", las actividades operativas tradicionales, como el inicio, el apagado, la copia de seguridad, etc. del sistema, se vuelven menos relevantes y, a menudo, pueden subcontratarse a un proveedor de la nube. En entornos y arquitecturas informáticas más tradicionales es mucho más probable que se requieran procedimientos operativos.

Es importante que los documentos se mantengan en un estado correcto y actualizado y, por lo tanto, deben estar sujetos a procedimientos formales de gestión de cambios y revisión periódica; esto es clave, ya que el auditor estará específicamente atento a esto.

A menudo nos preguntan cuántos detalles se necesitan y qué áreas del negocio necesitan tener procedimientos documentados. Adopte un enfoque de sentido común. Por ejemplo, si tiene una estabilidad real del personal, los procedimientos implícitos se entienden muy bien y existe resiliencia en todo ese conjunto de recursos, simples viñetas pueden ser suficientes para formar un procedimiento documentado estilo lista de verificación.

De manera similar, si los procedimientos están evolucionando o cambian periódicamente, por ejemplo debido al rápido crecimiento, es conveniente contar con procedimientos que también puedan actualizarse fácil y rápidamente. Nuevamente, si se agregan muchos recursos nuevos y el área presenta riesgos y complejidad, entonces puede ser necesario profundizar más los procedimientos para que no queden ambiguos sobre qué, cuándo, cómo, quién, etc.

Las áreas del negocio que deben considerarse para los procedimientos documentados deben ser aquellas en las que sus activos de información estén en riesgo debido a una operación incorrecta, lo que por supuesto se identificará como parte de la evaluación de riesgos de acuerdo con 6.1. Eso podría incluir desarrollo de software, gestión de TI, hasta contabilidad financiera, gestión de clientes, consultoría o trabajos de fabricación, etc., según la naturaleza del negocio.

A.12.1.2 Gestión de cambios

Es necesario controlar la organización, los procedimientos comerciales, las instalaciones de procesamiento de información y los sistemas que afectan la seguridad de la información. Una gestión de cambios adecuadamente controlada es esencial en la mayoría de los entornos para garantizar que los cambios sean apropiados, efectivos, debidamente autorizados y realizados de tal manera que se minimice la oportunidad de un compromiso malicioso o accidental. La gestión del cambio se aplica en toda la organización, sus procesos, instalaciones de procesamiento de información, redes, sistemas y aplicaciones.

Se requieren registros de auditoría para proporcionar evidencia del uso correcto de los procedimientos de cambio. El auditor querrá señalar que los procedimientos de cambio no tienen que ser demasiado complicados, pero sí deben ser apropiados a la naturaleza del cambio que se está considerando. Puede simplemente capturar evidencia de modificaciones y cambios de control de versiones a medida que avanza, u operar una gestión de cambios mucho más profunda y compleja e incluir reentrenamiento y comunicaciones, así como tener procesos de inversión y aprobación más significativos.

A.12.1.3 Gestión de capacidad

Se debe monitorear, ajustar y realizar proyecciones del uso de recursos de los requisitos de capacidad futuros para garantizar el rendimiento requerido del sistema para cumplir con los objetivos comerciales. La gestión de la capacidad normalmente analiza tres tipos principales; Capacidad de almacenamiento de datos (por ejemplo, en sistemas de bases de datos, áreas de almacenamiento de archivos, etc.); Capacidad de potencia de procesamiento – (por ejemplo, potencia computacional adecuada para garantizar operaciones de procesamiento oportunas); y Capacidad de comunicaciones (a menudo denominada “ancho de banda” para garantizar que las comunicaciones se realicen de manera oportuna).

La gestión de la capacidad también debe serlo; Proactivo: por ejemplo, utilizar consideraciones de capacidad como parte de la gestión del cambio; Reactivo: por ejemplo, activadores y alertas para cuando el uso de la capacidad esté alcanzando un punto crítico, de modo que se puedan realizar aumentos oportunos, temporales o permanentes.

A.12.1.4 Separación de los entornos de desarrollo, prueba y operación

Las buenas políticas para los entornos operativos, de prueba y de desarrollo confirmarían que deben estar separados para reducir los riesgos de acceso no autorizado o cambios en el entorno operativo. Mantener separados los entornos de TI operativos en vivo, de prueba y de desarrollo es una buena práctica, ya que esto ayuda con la segregación de tareas y el acceso no autorizado al entorno y a los datos en vivo. Los cambios y nuevos desarrollos deben probarse minuciosamente en un área separada antes de implementarlos en el entorno operativo real.

Idealmente, el personal de desarrollo no debería tener acceso al entorno real, pero esto puede no ser posible, especialmente en organizaciones pequeñas. Una vez separados, es importante comprobar que los evaluadores no estén utilizando accidentalmente (o deliberadamente) entornos de prueba como en vivo. El auditor verificará que los entornos de desarrollo, prueba y en vivo estén separados y que existan procedimientos formales que incluyan niveles apropiados de autorización para mover cambios y desarrollos de un entorno a otro.


¿Cuál es el objetivo del Anexo A.12.2?

El anexo A.12.2 trata sobre la protección contra malware. El objetivo aquí es garantizar que la información y las instalaciones de procesamiento de información estén protegidas contra el malware.

A.12.2.1 Controles contra malware

Se deben implementar controles de detección, prevención y recuperación para proteger contra el malware, combinados con la adecuada concienciación de los usuarios. Esta es una sección sobre la cual la mayoría de las organizaciones tienen cierto nivel de conocimiento, comprensión e implementación. Sin embargo, la protección contra malware puede adoptar varias formas diferentes además del obvio "software antivirus".

También son valiosos otros controles, como las restricciones en torno al uso de medios extraíbles o las restricciones a la instalación de software por parte de los usuarios, que ayudan a prevenir el uso de software no autorizado. También es fundamental parchear oportunamente las vulnerabilidades conocidas del sistema y del software. A menudo, los virus están diseñados para buscar sistemas y software sin parches en los que puedan residir vulnerabilidades conocidas. Es importante que cualquier protección contra malware se mantenga actualizada, tanto en términos de "archivos de firma" relevantes como del software en sí.


¿Cuál es el objetivo del Anexo A.12.3?

El anexo A.12.3 trata sobre la copia de seguridad. El objetivo es proteger contra la pérdida de datos.

A.12.3.1 Copia de seguridad de la información

Para proteger la información valiosa contra pérdidas, un buen control describe cómo se deben tomar y probar periódicamente copias de seguridad de la información, el software y las imágenes del sistema de acuerdo con una política de copia de seguridad acordada.

Los regímenes de respaldo deben diseñarse de acuerdo con los requisitos comerciales y los niveles de riesgo relacionados con la falta de disponibilidad de información, por lo que es importante garantizar que dichos regímenes respalden las necesidades reales en lugar de simplemente ser "nosotros hacemos respaldos". Cuando se realizan copias de seguridad, la información debe protegerse al mismo nivel que los datos en vivo como mínimo y debe almacenarse lejos del entorno en vivo para minimizar el riesgo de que un solo compromiso destruya tanto el entorno en vivo como las copias de seguridad.

Las pruebas periódicas de las copias de seguridad son cruciales para garantizar que las restauraciones sean exitosas y se realicen de manera oportuna. Se debe implementar el monitoreo y registro de las copias de seguridad para garantizar que se realicen de acuerdo con la política de copias de seguridad. Los auditores inteligentes querrán ver informes de las copias de seguridad fallidas y pruebas realizadas para garantizar que funcionan como se esperaba. Es necesario considerar políticas de copia de seguridad en torno a qué, dónde y hacia dónde, quién, cuándo, teniendo en cuenta a los trabajadores de oficina y a domicilio, los dispositivos móviles, etc., donde existen consideraciones sobre las copias de seguridad móviles y de almacenamiento remoto que tienen mayores riesgos en caso de pérdida que pueda ocurrir. abordados mediante cifrado u otros controles.


¿Cuál es el objetivo del Anexo A.12.4?

El anexo A.12.4 trata sobre el registro y el monitoreo. El objetivo en esta área del Anexo A es registrar eventos y generar evidencia.

A.12.4.1 Registro de eventos

Es necesario producir, mantener y revisar periódicamente registros de eventos que registren las actividades de los usuarios, excepciones, fallas y eventos de seguridad de la información. Los mecanismos de registro y monitoreo forman una parte importante de una estrategia de “defensa en profundidad” para la gestión de la seguridad al proporcionar capacidades tanto de detección como de investigación. Es posible que se requieran registros de eventos de todo tipo, por ejemplo, registros del sistema, registros de control de acceso, etc., especialmente en lo que respecta a la gestión y auditoría de incidentes. Los registros a menudo necesitarán almacenar cantidades potencialmente enormes de información, por lo que es importante tener en cuenta la capacidad.

A.12.4.2 Protección de la información de registro

Las instalaciones de registro y la información de registro deben protegerse contra manipulación y acceso no autorizado. También es fundamental garantizar que los registros se almacenen de forma segura y a prueba de manipulaciones para que cualquier evidencia derivada de ellos pueda demostrarse de manera demostrable. Esto es especialmente importante en cualquier tipo de procedimiento legal relacionado con las pruebas del registro. Dado que los registros contienen potencialmente grandes cantidades de datos confidenciales, es importante que estén protegidos y protegidos adecuadamente. También es importante considerar que si los registros contienen información de identificación personal, lo cual es casi seguro que lo harán, como la identificación del usuario y las acciones realizadas por ese UID, es probable que cumplan con los requisitos de la legislación de privacidad y protección de datos, incluida la retención de datos. .

A.12.4.3 Registros de administrador y operador

Un buen control describe cómo se deben registrar las actividades del administrador y del operador del sistema y cómo se deben proteger y revisar periódicamente los registros. Se debe prestar especial atención a mayores niveles de registro para cuentas privilegiadas, como administradores y operadores de sistemas.

A.12.4.4 Sincronización del reloj

Los relojes de todos los sistemas de procesamiento de información relevantes dentro de una organización o dominio de seguridad deben sincronizarse con una única fuente de tiempo de referencia. La sincronización del reloj del sistema es importante, especialmente cuando se prueban eventos como parte de una investigación o procedimiento legal, ya que a menudo es imposible o muy difícil probar "causa y efecto" si los relojes no están sincronizados correctamente. El auditor prestará especial atención para garantizar que esto se haya hecho.


¿Cuál es el objetivo del Anexo A.12.5?

El anexo A.12.5 trata sobre el control del software operativo. El objetivo en esta área del Anexo A es garantizar la integridad de los sistemas operativos.

A.12.5.1 Instalación de software en sistemas operativos

Se deben implementar procedimientos para controlar la instalación de software en los sistemas operativos. Como ocurre con cualquier control relacionado con la seguridad, es importante que la instalación de software en los sistemas operativos esté controlada formalmente. Aunque esto no siempre sea posible, especialmente en organizaciones pequeñas, el principio sigue siendo válido. Los problemas relacionados con la instalación inadecuada o el cambio de software en sistemas operativos pueden incluir: Se está instalando software infectado con malware; Problemas de capacidad; o Software que puede permitir la instalación de actividades internas maliciosas (por ejemplo, herramientas de piratería). Más allá de restringir y limitar la instalación de software en sistemas operativos, también es importante controlar formalmente la instalación legítima.

Es una buena práctica garantizar, siempre que sea posible, que, por ejemplo; Se ha llevado a cabo una gestión formal del cambio, incluidos niveles apropiados de autorización; Se han establecido procedimientos de reversión; y Las versiones anteriores del software y los historiales de cambios se mantienen de forma segura. Cada cambio debe considerar tanto los requisitos comerciales como los requisitos y riesgos de seguridad en línea con los procedimientos formales de gestión de cambios. El auditor esperará ver registros de los cambios e instalaciones de software que se han conservado, los cuales querrá inspeccionar/muestrear.


¿Cuál es el objetivo del Anexo A.12.6?

El anexo A.12.6 trata sobre la gestión de vulnerabilidad técnica. El objetivo en esta área del Anexo A es evitar la explotación de vulnerabilidades técnicas.

A.12.6.1 Gestión de vulnerabilidades técnicas

Se debe obtener información sobre las vulnerabilidades técnicas de los sistemas de información que se utilizan de manera oportuna, evaluar la exposición de la organización a dichas vulnerabilidades y tomar las medidas adecuadas para abordar el riesgo asociado. Cualquier vulnerabilidad es una debilidad en la protección de la seguridad y debe abordarse de manera efectiva y eficiente cuando los niveles de riesgo sean inaceptables. Las vulnerabilidades técnicas han estado en el centro de muchas grandes violaciones de seguridad reportadas en los medios (¡y de aquellas que no lo son!), por lo que es esencial que existan procesos gestionados formales a un nivel adecuado y proporcionado.

Es necesario que haya un equilibrio entre el imperativo de seguridad de implementar parches de vulnerabilidad lo más rápido posible y el imperativo de seguridad de probar los parches lo suficiente como para garantizar la disponibilidad e integridad continua de los sistemas y la minimización de incompatibilidades. La concientización también puede desempeñar un papel importante y, por lo tanto, es sensato tener una estrategia de comunicación relacionada con la actualización de los usuarios cuando existen vulnerabilidades que pueden gestionarse hasta cierto punto a través del comportamiento de los usuarios. El auditor esperará ver que existan procesos para identificar y detectar vulnerabilidades, especialmente en sistemas críticos o aquellos que procesan o almacenan información confidencial o clasificada.

A.12.6.2 Restricciones a la instalación de software

Es necesario establecer e implementar reglas que regulen la instalación de software por parte de los usuarios. Este control se relaciona con restringir la capacidad de los usuarios para instalar software, especialmente en dispositivos locales (estaciones de trabajo, computadoras portátiles, etc.). La instalación de software por parte de los usuarios plantea una serie de amenazas y vulnerabilidades, incluida la amenaza de introducción de malware y la posible violación de las leyes de licencias de software/DPI. Lo ideal sería que los usuarios no pudieran instalar ningún software en el equipo de la organización; sin embargo, puede haber razones comerciales o prácticas por las que esto no sea posible.

Cuando no sea posible una restricción total, es una buena práctica incluir en una “lista blanca” el software que se puede instalar. El auditor comprobará qué restricciones se han impuesto a la instalación de software por parte de los usuarios. Luego, cuando no se implemente una restricción total, querrán ver evidencia de que los riesgos se han evaluado completamente y, cuando sea posible, se han implementado y se utilizan regularmente controles complementarios, como auditorías periódicas de software.


¿Cuál es el objetivo del Anexo A.12.7?

El Anexo A.12.7 trata sobre sistemas de información y consideraciones de auditoría. El objetivo en esta área del Anexo A es minimizar el impacto de las actividades de auditoría en los sistemas operativos.

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

Los requisitos de auditoría y las actividades que implican la verificación de sistemas operativos deben planificarse y acordarse cuidadosamente para minimizar las interrupciones en los procesos comerciales. Siempre que se lleven a cabo pruebas y actividades de auditoría (por ejemplo, análisis de vulnerabilidades, pruebas de penetración, etc.) en sistemas operativos, se debe tener en cuenta que las operaciones no se vean afectadas negativamente. Además, se debe definir el alcance y la profundidad de las pruebas. Cualquier auditoría o prueba de sistemas operativos debe realizarse a través de un proceso formal y debidamente autorizado. El auditor buscará evidencia de que la programación de las pruebas y el nivel de las pruebas se acuerdan y autorizan mediante un proceso formal.

Obtenga una ventaja inicial del 81%

Hemos hecho el trabajo duro por usted, brindándole una ventaja inicial del 81 % desde el momento en que inicia sesión.
Todo lo que tienes que hacer es completar los espacios en blanco.

Reserve una demostración

Requisitos de la norma ISO 27001


Controles ISO 27001 Anexo A


Acerca de ISO 27001


ISMS.online ahora es compatible con ISO 42001, el primer sistema de gestión de IA del mundo. Haga clic para saber más