La versión más actual de la norma ISO/IEC 27002 fue publicada el 15 de febrero de 2022 y entre sus novedades encontramos que hay un cambio significativo en el número de controles, donde ahora se tienen 93 controles de seguridad frente a los 114 de la versión del 2013.
Al revisar un poco más en profundidad los controles encontramos que la organización de los controles pasa de 14 cláusulas a 4 cambiando también la estructura en que se documenta cada uno de los controles.
Todos estos cambios traen un refresco a los controles dando una visión más alineada con los cambios tecnológicos de los últimos años, incluyendo temas relacionados con la nube que se echaban en falta y consolidando algunos que de uno u otro modo se veían como repetitivos. Su estructura presenta mecanismos que permiten facilitar la búsqueda de controles de acuerdo con diferentes clasificaciones que se les dan a ellos.
Esta estructura organiza los controles en 4 categorías o cláusulas:
- Controles organizacionales (37)
- Controles de personas (8)
- Controles físicos (14)
- Controles tecnológicos (34)
Y cada control tiene documentados atributos de diferentes tipos descritos a continuación:
| Tipo de control |
#Preventivo: el control que pretende evitar que se produzca un incidente de seguridad de la información |
| #Detectivo: el control actúa cuando se produce un incidente de seguridad de la información |
| #Correctivo: el control actúa después de que se produzca un incidente de seguridad de la información |
| Propiedades de seguridad de la información |
#Confidencialidad |
| #Integridad |
| #Disponibilidad |
| Conceptos de ciberseguridad (tomados de la ISO/IEC TS 27110) |
#Identificar |
| #Proteger |
| #Detectar |
| #Responder |
| #Recuperar |
| Capacidades operativas |
#Gobierno |
| #Gestión_de_activos |
| #Protección_de_la_información |
| #Seguridad_de_los_recursos_humanos |
| #Seguridad_física |
| #Seguridad_del_sistema_y_de_la_red |
| #Seguridad_de_las_aplicaciones |
| #Configuración_segura |
| #Gestión_de_identidad_y_acceso |
| #Gestión_de_amenazas_y_vulnerabilidades |
| #Continuidad |
| #Seguridad_de_las_relaciones_con_los_proveedores |
| #Cumplimiento_y_legal |
| #Gestión_de_eventos_de_seguridad_de_la_información |
| #Garantizar_la_seguridad_de_la_información |
| Dominios de seguridad |
#Gobierno_y_ecosistema: incluye "Gobierno de la seguridad de los sistemas de información y gestión de riesgos" y "Gestión de la ciberseguridad del ecosistema" |
| #Protección: incluye "Arquitectura de seguridad de las tecnologías de la información", "Administración de la seguridad de las tecnologías de la información", "Gestión de la identidad y el acceso", "Mantenimiento de la seguridad de las tecnologías de la información" y "Seguridad física y medioambiental" |
| #Defensa: incluye "Detección" y "Gestión de incidentes de seguridad informática" |
| #Resiliencia: incluye "Continuidad de las operaciones" y "Gestión de crisis" |
En este artículo se presenta un análisis de los controles organizacionales que se recogen en ISO/IEC 27002:2022.
Políticas de seguridad de la información (5.1)
Este control nos indica la necesidad de crear un documento o conjunto de documentos que contengan las directrices de cómo la organización gestiona sus objetivos de seguridad de la información en los diferentes procesos y tecnologías asociados. Estos documentos deben ser aprobados por la dirección y deben contener políticas de alto y bajo nivel. Una vez establecidas las políticas, deben revisarse periódicamente, de preferencia de manera anual y cuando la organización, procesos o tecnologías asociadas sufran un cambio significativo. El mejor enfoque es fijar al menos una reunión anual o, mejor aún, planificar reuniones adicionales a lo largo del periodo si la situación lo requiere. Si se realizan cambios, la dirección debe dar su aprobación. Las políticas deben compartirse con las partes interesadas internas y externas asegurando su lectura y comprensión.
Funciones y responsabilidades en materia de seguridad de la información (5.2)
En este control se indica que la política de seguridad de la información de forma clara y documentada debe definir quién es responsable de cada actividad, proceso o tarea que suponga un riesgo para la seguridad de la información. Esto incluye todas las tareas o actividades que puedan influir en la confidencialidad, integridad y/o disponibilidad de la información. Es necesario garantizar que las funciones y responsabilidades sean adecuadas para la organización, como también se solicita en la cláusula 5.3 de la norma ISO/IEC 27001:2022. Una asignación clara de responsabilidades evita vacíos de control, duplicidades y malentendidos, y facilita la rendición de cuentas. Las funciones asignadas deben ser coherentes con el tamaño, estructura y contexto de la organización, y contar con el respaldo explícito de la dirección .
Segregación de funciones (5.3)
Para reducir el riesgo de fraude, errores o uso indebido de los activos, las actividades críticas deben dividirse entre distintas personas o roles. Ninguna persona debería tener control total sobre una actividad que pueda generar un impacto significativo en la seguridad de la información, el "poder" de controlar totalmente una actividad "crítica" no debe estar en manos de la misma persona. La actividad "crítica" no debe ser llevada a cabo por la misma persona. La mejor manera de implementar este control es registrar todas las actividades y dividir las actividades importantes en ejecución, control o aprobación y la iniciación.
Responsabilidad de la dirección (5.4)
La alta dirección debe demostrar un compromiso alto con la seguridad de la información, esto significa que se debe garantizar que todos los empleados y contratistas conocen, comprenden y cumplen con las políticas, normas y procedimientos de seguridad de la información de la organización.
Además de aprobar políticas, la dirección debe predicar con el ejemplo, integrando la seguridad de la información en la cultura organizacional y reforzando su importancia como un habilitador del negocio, no como un obstáculo, por tanto, deben dar ejemplo y demostrar que la seguridad de la información es útil y necesaria.
Contacto con las autoridades (5.5)
La organización debe definir claramente cuándo, cómo y quién es el responsable de ponerse en contacto con las autoridades competentes (por ejemplo, las fuerzas del orden, los organismos reguladores, los supervisores (por ejemplo, cuerpos de seguridad, organismos reguladores, autoridades de supervisión), con qué autoridades hay que ponerse en contacto (por ejemplo, en qué región/país), en qué países y en qué casos debe hacerse. Una respuesta rápida y adecuada a los incidentes puede reducir significativamente el impacto e incluso puede ser obligatorio por ley.
Contacto con grupos de interés especiales (5.6)
Para garantizar la actualización frente a amenazas, vulnerabilidades, últimas tendencias y mejores prácticas en materia de seguridad de la información, la organización debe fomentar que el personal con tareas de SGSI mantenga un buen contacto con los grupos especializados en seguridad de la información.
En algunos casos, estos grupos pueden ser solicitados para el asesoramiento de expertos y ser un punto de referencia en temas de seguridad de la información. Pueden incluir asociaciones profesionales, comunidades técnicas, organismos gubernamentales o equipos de respuesta a incidentes. Ejemplos de estos grupos son: el IAPP, el grupo de seguridad de LinkedIn, ISACA, ISC2, organizaciones gubernamentales específicas (ministerios de tecnología), CSIRT locales, de industria o gremio, regionales y/o globales.
Inteligencia sobre amenazas (5.7)
La organización debe recopilar y analizar información relevante sobre amenazas actuales y emergentes que puedan afectar a su contexto. Esto significa que reaccionar ante las amenazas no sirve para evitar que se produzcan por primera vez. Al recopilar y analizar la información sobre el entorno de amenazas de la organización, se tendrá una mejor idea de los mecanismos de protección que deben establecerse para protegerse contra las amenazas que son relevantes para la organización.
Este enfoque proactivo permite anticiparse a los ataques, ajustar los controles de seguridad y priorizar recursos en función de amenazas reales y relevantes, en lugar de reaccionar únicamente cuando ocurre un incidente.
Seguridad de la información en la gestión de proyectos (5.8)
Este control nos indica que para garantizar el éxito de la implantación del SGSI a nivel de la organización, la seguridad de la información debe ser considerada y documentada en el plan de gestión de los proyectos. La seguridad debe considerarse y documentarse en todos los proyectos en forma de requisitos. Estos requisitos pueden derivarse de las actividades empresariales y legales y del cumplimiento de otras normas o reglamentos. Si se tienen manuales o plantillas de gestión de proyectos, deberían incluir un capítulo sobre la seguridad de la información.
Esto garantiza que los nuevos sistemas, procesos o cambios organizativos no introduzcan riesgos innecesarios y que la seguridad forme parte natural de la toma de decisiones del proyecto.
Inventario de información y otros activos asociados (5.9)
La organización debe identificar todos los activos de información y de procesamiento de la información, estos activos deben recopilarse en un inventario, que debe ser debidamente mantenido. Saber qué activos hay, su importancia, dónde se encuentran y cómo se gestionan es esencial para identificar y predecir los riesgos. También puede ser obligatorio por compromisos legales, contractuales o para efectos del seguro. Todos los activos del inventario, y por tanto toda la empresa si el inventario es completo, deben tener un propietario (es decir, un responsable). Gracias a la propiedad de los recursos, éstos pueden ser monitoreados y gestionados a lo largo de su ciclo de vida. Las actividades similares pueden agruparse y la supervisión diaria de una actividad puede encomendarse a un llamado custodio, pero el propietario sigue siendo responsable. La propiedad de los recursos debe ser aprobada por la dirección.
Uso aceptable de la información y otros recursos asociados (5.10)
Deben establecerse reglas claras y documentadas para el acceso a los recursos de información. Los usuarios del recurso deben conocer los requisitos de seguridad de la información relacionados con el uso del recurso y cumplirlos. También deben establecerse procedimientos para la gestión de los activos. El personal debe entender el etiquetado de los activos y saber manejar los diferentes niveles de clasificación (véase 5.12). Dado que no existe una norma universal de clasificación, también es importante conocer los niveles de clasificación de otras partes, ya que es muy probable que difieran de los de la organización.
Esto ayuda a prevenir usos indebidos, pérdidas de información y exposiciones innecesarias, especialmente cuando se manejan distintos niveles de clasificación o información de terceros.
Rendimiento de los activos (5.11)
Deben establecerse procesos efectivos que garanticen que cuando un empleado o una parte externa ya no deba acceder a un activo debido, por ejemplo, a la terminación de la relación laboral o de un contrato, debe desactivarse o se debe devolver el bien a la organización. Por tanto, debe existir una política clara al respecto, que debe ser conocida por todas las partes implicadas. Los activos intangibles importantes para las operaciones actuales, como los conocimientos específicos que aún no están documentados, deben ser documentados y entregados a la organización para evitar pérdidas operativas o de seguridad.
Clasificación de la información (5.12)
Algunas informaciones en la organización se consideran sensibles, por ejemplo, por su valor monetario o legal, y deben ser confidenciales, mientras que otras informaciones son menos importantes. La organización debe tener una política sobre cómo manejar la información y para esto debe indicar cómo clasificarla. La responsabilidad de clasificar los recursos de información recae en su propietario. Para distinguir la importancia de los diferentes activos clasificados, puede ser útil aplicar distintos niveles de confidencialidad, desde la inexistencia hasta el impacto severo en la supervivencia de la organización.
La clasificación facilita la aplicación de controles adecuados y asegura que la información más sensible reciba un nivel de protección acorde a su importancia para la organización.
Etiquetado de la información (5.13)
No toda la información entra en la misma categoría, como se ha comentado en el control anterior. Por lo tanto, es importante etiquetar toda la información según su clasificación. Esto debe ocurrir cuando se manipula, almacena o intercambia la información ya que durante su uso puede ser esencial conocer la clasificación del objeto. Desafortunadamente, esto puede ser útil para personas malintencionadas ya que se convierte en una guía de objetos interesantes y por tanto es importante ser consciente de este riesgo.
Transferencia de información (5.14)
Este control nos indica que la información cuando se comparte dentro y fuera de la organización debe seguir un protocolo para todo tipo de intercambio de información, incluidos los documentos digitales, los documentos físicos, los vídeos, pero también el boca a boca (transmisión verbal de información). Tener unas normas claras sobre cómo compartir la información de forma segura ayudan a reducir el riesgo de contaminación y pérdida de información. La información compartida entre la organización y las partes externas debe ir precedida de un acuerdo de transferencia. De este modo, la fuente, el contenido, la confidencialidad, el medio de transferencia y el destino de la transferencia de información son conocidos y acordados por ambas partes.
La comunicación empresarial se realiza a menudo a través de la mensajería electrónica. Se recomienda que las organizaciones tengan una visión general de los tipos de mensajería electrónica aprobados y que documenten cómo están protegidos y pueden utilizarse para transferir información.
Control de acceso (5.15)
Este control nos indica que debe existir una política de control de acceso para definir cómo se gestiona el acceso y quién está autorizado a acceder a qué. Las normas de acceso a cada activo son responsabilidad de los propietarios de los activos, que establecen los requisitos, restricciones y derechos de acceso a "su" activo. Los términos que con frecuencia son utilizados en una política de control de acceso son la necesidad de conocer y necesidad de uso, donde la primera limita el acceso sólo a la información que un empleado necesita para realizar su tarea y el segundo limita el acceso sólo a la infraestructura de tecnología de la información dónde existe una necesidad clara de acceso para realizar su tarea.
En segundo lugar, limitar los derechos de acceso únicamente a las instalaciones de procesamiento de información necesarias para realizar la tarea.
Gestión de identidades (5.16)
Para asignar derechos de acceso a activos y redes y hacer un seguimiento de quién accede realmente, es necesario registrar a los usuarios con un identificador único de usuario. Cuando un empleado abandona la organización debe eliminarse el identificador de usuario con sus privilegios de acceso.
Aunque utilizar la identificación de otro empleado pueda ser más rápido y fácil para acceder a algo, esto no debe ser permitido por la dirección. Compartir identificadores de usuario elimina el vínculo entre una limitación de acceso y un empleado, y hace casi imposible mantener a la persona correcta responsable de sus acciones.
Asignar, alterar y, en última instancia, eliminar una identidad suele denominarse ciclo de vida de la identidad.
Información de autenticación (5.17)
Este control nos indica que los secretos utilizados para la autenticación, como contraseñas, tarjetas de acceso, tokens u otros mecanismos de autenticación, deben gestionarse en un proceso formal y seguro. Otras actividades importantes que deben figurar en la política son, por ejemplo, prohibir a los usuarios compartir información secreta de autenticación, dar a los nuevos usuarios una contraseña diferente para cada usuario y que debe cambiarse en el primer uso, y hacer que todos los sistemas autentiquen a un usuario requiriendo su información secreta de autenticación (contraseña en el PC, pasar la tarjeta de acceso por las puertas).
Si se utilizan sistemas de gestión de contraseñas, deben proporcionar buenas contraseñas y seguir estrictamente la política de autenticación de la organización. Las propias contraseñas deben ser almacenadas y transmitidas de forma segura por el sistema de gestión de contraseñas.
Derechos de acceso (5.18)
Este control y nos indica que la organización debe disponer de un proceso controlado y documentado para la concesión y revocación de derechos de acceso. Se aconseja crear roles en función de las actividades que realizan determinados tipos de empleados y otorgarles los mismos derechos de acceso básicos. El objetivo de tener un sistema de autenticación es tener registros de los intentos de acceso no autorizado. Los empleados no tienen por qué intentar acceder a lugares a los que no deberían, ya que los derechos de acceso pueden solicitarse fácilmente al propietario del activo y/o a la dirección.
Las organizaciones y sus empleados no son estáticos. Las funciones cambian o los empleados abandonan la empresa, lo que modifica constantemente las necesidades de acceso, por este motivo, los propietarios de los activos deben revisar periódicamente quién puede acceder a sus activos, mientras que el cambio de funciones o el abandono de la empresa debe desencadenar una revisión de los derechos de acceso por parte de la dirección. Dado que los derechos de acceso privilegiados son más sensibles, deben revisarse con más frecuencia. Una vez rescindido un contrato o acuerdo, deben eliminarse los derechos de acceso de la parte receptora.
Seguridad de la información en las relaciones con los proveedores (5.19)
El control nos indica que, dado que los proveedores tienen acceso a ciertos activos, las organizaciones necesitan establecer una política que establezca los requisitos para la mitigación de riesgos que se abren cuando se da acceso a los activos de información.
Esta política debe ser comunicada a los proveedores y acordada. Ejemplos de tales requisitos son procesos logísticos predeterminados, un proceso de incidentes obligatorio para ambas partes, acuerdos de confidencialidad y documentación del proceso de suministro.
Abordar la seguridad de la información en los acuerdos con proveedores (5.20)
El control nos indica que, todo proveedor que, de alguna manera, directa o indirectamente entre en contacto con la información de la organización debe seguir los requisitos de seguridad de la información establecidos y aceptarlos. Algunos ejemplos son los requisitos sobre clasificación de la información, uso aceptable y derechos de auditoría. Un aspecto que se olvida fácilmente en un acuerdo es qué hacer cuando el proveedor no puede o no quiere seguir proveyendo su producto o servicio. Por tanto, indispensable incluir cláusulas específicas de seguridad de la información.
Esto asegura que los proveedores comprendan y acepten sus responsabilidades, así como las consecuencias de incumplimiento o de finalización del servicio.
Gestión de la seguridad de la información en la cadena de suministro de las TIC (5.21)
El control nos indica que, los acuerdos con los proveedores también deben establecer los requisitos de seguridad de la información y los acuerdos sobre los servicios de TIC y la cadena de suministro. Ejemplos de requisitos incluidos son la necesidad de poder seguir los productos a lo largo de la cadena de suministro, y que se mantenga un cierto nivel mínimo de seguridad en cada nivel o eslabón de la "cadena de suministro".
Seguimiento, revisión y gestión de los cambios en los servicios de los proveedores (5.22)
Este control nos recuerda que todo el mundo comete errores, y los proveedores también. Tanto si el error se ha producido por accidente o deliberadamente, el resultado es el mismo: la organización no recibe exactamente lo que se ha acordado y la confianza puede disminuir. Por esta razón, la organización debe vigilar a los proveedores y auditarlos cuando lo consideren necesario. De este modo, una organización es consciente de cuándo un proveedor hace algo fuera de lo normal.
Al igual que con los cambios de sistema, la dirección debe controlar cualquier cambio en los servicios de los proveedores. Tienen que asegurarse de que las políticas de seguridad de la información están actualizadas y de que se gestiona cualquier cambio en la prestación del propio servicio. Un pequeño cambio en el servicio prestado, combinado con una política de seguridad de la información obsoleta, podría dar lugar a un nuevo gran riesgo. Los cambios en el proveedor pueden producirse fácilmente, por ejemplo, cuando se mejora el servicio, se suministra una nueva aplicación o sistema, o cambian las políticas y procedimientos del proveedor.
Seguridad de la información al utilizar servicios en la nube (5.23)
Este control nos indica que los proveedores en la nube ofrecen un servicio que, cuando se utiliza, suele ser una parte vital de la infraestructura de la organización. Por ejemplo, los documentos de Office se almacenan en la nube, muchos proveedores de SaaS ofrecen su producto a sus clientes a través de un proveedor en la nube como Amazon AWS, Microsoft Azure o Google Cloud.
Los riesgos que rodean a esta parte crítica de la organización deben mitigarse adecuadamente. Las organizaciones deben contar con procesos para utilizar, gestionar y abandonar (estrategia de salida) una nube utilizada. Romper los lazos con un proveedor de nube a menudo significa que un nuevo proveedor de nube está en el horizonte, por lo que tampoco debe olvidarse el control de la compra y la incorporación a una nueva nube. Al igual que cualquier otro software de terceros, un nuevo entorno de nube debe permitir mantener el nivel deseado de seguridad de la información, no comprometerlo.
Planificación y preparación de la gestión de incidentes de seguridad de la información (5.24)
El control nos indica que, las organizaciones necesitan crear y documentar procedimientos para gestionar los incidentes de seguridad de la información, y quién es responsable de qué, es decir, definir los roles y las responsabilidades dentro de este proceso. De este modo, si se produce un incidente de seguridad de la información, puede gestionarse con eficacia y rapidez. Los incidentes de seguridad ocurren de forma inesperada y pueden provocar cierto caos, que puede mitigarse disponiendo de un protocolo seguido por personal informado y formado.
Evaluar y decidir sobre los incidentes de seguridad de la información (5.25)
El control nos indica que, la organización debe disponer de criterios y métodos de evaluación de incidentes de seguridad bien documentados. Cuando se produce un suceso sospechoso, la persona responsable debe contrastar el suceso con los criterios y determinar si se ha producido realmente un incidente de seguridad de la información. Los resultados de esta evaluación deben documentarse para que puedan utilizarse como referencia en el futuro en los casos o situaciones en que no se tengan documentados los criterios o métodos para sucesos específicos.
Respuesta a los incidentes de seguridad de la información (5.26)
Una vez que se confirma que ha ocurrido un incidente de seguridad de la información, el personal designado debe responder al mismo siguiendo los procedimientos establecidos. Deben adoptarse las medidas predeterminadas y documentarse con precisión todo el proceso. Esto ayuda a contener el incidente, restaurar los servicios y prevenir futuros incidentes y a eliminar las vulnerabilidades de seguridad relacionadas.
Aprender de los incidentes de seguridad de la información (5.27)
Aunque los incidentes son un evento no deseado, siguen teniendo un gran valor para la organización. Los conocimientos adquiridos al resolver un incidente deben analizarse para identificar causas raíz y oportunidades de mejora y de esta manera utilizarse para prevenir incidentes similares en el futuro, y pueden ayudar a identificar un posible problema sistemático. Con los controles adicionales, es importante vigilar los costos; un nuevo control no debe costar a la organización anualmente más que los incidentes que mitiga.
Recolección de pruebas (5.28)
Cuando se produce un incidente, la causa no suele estar clara de inmediato, por esta razón deben recogerse y protegerse las pruebas de forma adecuada para los análisis posteriores.
Cuando la causa es un individuo o una organización, hay que aplicar el proceso disciplinario en función de la intención y el efecto. Para vincular un incidente a una causa, se deben usar las pruebas recolectadas. En caso de acción dolosa, estas pruebas y la forma en que se obtuvieron podrían utilizarse en procedimientos judiciales. Para evitar la destrucción accidental o deliberada de pruebas, debe existir un procedimiento de identificación de pruebas claro y seguro.
Seguridad de la información durante la interrupción (5.29)
Este control nos habla sobre el deber que tiene la organización para determinar sus requisitos para la continuidad de la seguridad de la información en caso de crisis. La opción más sencilla es reanudar las actividades estándar de seguridad de la información lo mejor posible en una situación adversa. Una vez determinados y acordados los requisitos en la dirección, deben establecerse procedimientos, planes y controles para reanudar con un nivel aceptable la seguridad de la información en caso de crisis.
A medida que cambian las organizaciones, cambia también la mejor manera de responder a una crisis. Una organización que, por ejemplo, haya duplicado su tamaño en el plazo de un año, muy probablemente se beneficiará de una respuesta diferente a la de hace un año. Por esta razón, los controles de continuidad de la seguridad de la información se deben revisar y actualizar de forma periódica.
Preparación de las TIC para la continuidad de la actividad (5.30)
Este es un control nos indica que, durante la planificación de la Continuidad de Negocio, debe prestarse especial atención a los escenarios en los que fallan los sistemas informáticos. Debe existir una estrategia clara sobre cómo se restaurarán los sistemas, quién lo hará y cuánto tiempo puede llevar. También debe quedar claro qué significa "restaurar" en un escenario concreto, ya que es probable que sólo funcionen los sistemas básicos o críticos durante la primera semana tras un colapso total.
Identificación de los requisitos legales, reglamentarios y contractuales (5.31)
Este control nos indica que los requisitos de seguridad de la información provienen de múltiples fuentes, esto incluye leyes, regulaciones y contratos, especialmente cuando la organización opera en múltiples jurisdicciones, y están ahí para ser cumplidos. Por lo tanto, las organizaciones deben tener una visión general de todos los requisitos relacionados con la seguridad de la información que deben cumplir y de cómo hacerlo. Dado que los requisitos pueden cambiar o añadirse, la visión general del cumplimiento de los requisitos debe mantenerse actualizada. Un ejemplo de cambio de requisitos es cuando su organización se expande a un nuevo país en un continente diferente, o establece un contrato con un cliente nuevo que impone condiciones diferentes de seguridad. Es probable que este país tenga leyes diferentes sobre privacidad, almacenamiento de información y criptografía o que el nuevo contrato requiera condiciones o tiempos de almacenamiento de información diferentes a los que maneja la organización, o que incluso, exija el cumplimiento de un estándar de seguridad de la información que actualmente no se tiene en la organización.
Derechos de propiedad intelectual (5.32)
Este control habla sobre los derechos de propiedad intelectual (PI), que también forman parte del cumplimiento legal, son un área que merece especial atención. La PI puede ser de gran valor, por lo que es importante documentar bien la propiedad intelectual propia y el uso de la ajena. El uso (accidental) incorrecto de la PI ajena puede dar lugar a grandes demandas, y debe evitarse a toda costa.
Protección de los registros (5.33)
Este control nos indica que, todos los registros, ya sean contables, de proceso o de auditoría, deben estar protegidos. Los registros corren el riesgo de perderse, verse comprometidos o de que se acceda a ellos sin autorización. Los requisitos de protección de los registros pueden proceder de la propia organización o de otras fuentes, como la legislación o las compañías de seguros. Para ello, deben crearse y seguirse unas directrices claras y estrictas.
Privacidad y protección de la información personal identificable (5.34)
El control nos indica que, dependiendo del país o espacio económico en el que se encuentre una organización, puede aplicarse una legislación diferente en materia de protección de datos personales. A las organizaciones situadas en la UE y/o que tratan datos personales de ciudadanos de la UE se les aplica el Reglamento General de Protección de Datos (RGPD). Las organizaciones deben asegurarse de que son conscientes de los requisitos establecidos por dicha legislación, y seguirla religiosamente. El RGPD, por ejemplo, obliga a celebrar acuerdos de tratamiento de datos, mantener un registro de la actividad de tratamiento y transparencia en el tratamiento de datos. Muchos países cuentan hoy con regulaciones equivalentes que buscan cumplir el mismo objetivo, proteger la información personal, todas estas regulaciones deben cumplirse ya sea porque la organización está operando en ese entorno geográfico o porque da servicio a clientes que están en esas circunscripciones.
Es importante tener en cuenta que además de este control, siguen siendo válidos los controles previstos en las normas ISO/IEC 27018 y ISO/IEC 27701.
Revisión independiente de la seguridad de la información (5.35)
Este control nos indica que, es imposible que las organizaciones revisen objetivamente su propio sistema de seguridad de la información. Por esta razón, las organizaciones deben hacer auditar su sistema de gestión de seguridad de la información por una parte independiente de forma regular, o cuando se produzcan grandes cambios. De este modo, la organización mantiene una visión correcta y transparente del estado de su seguridad de la información. Una parte independiente también puede ser un auditor interno a tiempo completo, que tenga la única tarea de realizar las auditorías internas y no tenga otras tareas y responsabilidades conflictivas.
Cumplimiento de las políticas y normas de seguridad de la información (5.36)
Este control nos indica que, el cumplimiento de todas las políticas, normas y procedimientos de seguridad debe ser revisado periódicamente para asegurar que las actividades y/o procesos de los que son responsables se llevan a cabalidad. Para hacerlo con corrección, los responsables deben saber exactamente qué normas y requisitos deben cumplir y comprobarlo manualmente o con una herramienta automática de elaboración de informes.
Los sistemas de información también deben revisarse periódicamente para comprobar su cumplimiento. La forma más sencilla y, por lo general, más rentable de hacerlo es mediante herramientas automatizadas. Estas herramientas pueden comprobar rápidamente todos los recovecos de un sistema e informar exactamente de lo que ha ido o podría ir mal. Las pruebas de vulnerabilidad, como las pruebas de penetración, pueden mostrar eficazmente cualquier punto débil, pero en realidad podrían dañar el sistema si se hacen sin precaución.
Procedimientos operativos documentados (5.37)
El control nos indica que, los procedimientos de funcionamiento de las tareas operativas, las aplicaciones y los equipos deben documentarse y ponerse a disposición de quienes los utilicen. Desde el simple procedimiento de uso de un ordenador (desde el arranque hasta el apagado) hasta el uso de equipos más complicados, debe existir una guía sobre cómo manejarlos de forma segura y correcta. Debido a su importancia, los procedimientos deben tratarse como documentos formales, lo que significa que cualquier cambio debe ser aprobado por la dirección.
Referencias
ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection — Information security controls, https://www.iso.org/standard/75652.html
ISO/IEC 27002:2013, Information technology — Security techniques — Code of practice for information security controls, https://www.iso.org/standard/54533.html