Tag ISO

Repasamos los cambios en las cláusulas establecidos en la última versión de la ISO 27001, el estándar para la gestión de la seguridad de una organización.

En un artículo anterior abordamos los cambios en la nueva versión de ISO/IEC 27001 (ISO/IEC 27001:2022) con relación a los controles de seguridad considerados en el Anexo A, ya que representaron los cambios más significativos para la edición 2022. En esta oportunidad revisaremos los cambios en las cláusulas del estándar.

Recordemos que las cláusulas definen los requisitos para establecer, implementar, mantener y mejorar continuamente un Sistema de Gestión de Seguridad de la Información (SGSI). Además, incluye los requisitos para la evaluación y el tratamiento de los riesgos de seguridad de la información, identificados para cada organización.

Imagen 1. Cláusulas normativas de ISO/IEC 27001.

La sexta cláusula (Planeación) muestra los requisitos del estándar relacionados con la evaluación de riesgos de seguridad de la información; también considera los requisitos para el tratamiento de estos luego de que han sido identificados, analizados y evaluados en función de los criterios de aceptación. Por último, incluye los objetivos de seguridad de la información que se pretenden lograr a través del sistema de gestión.

Los cambios son minúsculos para esta cláusula. En el caso del requisito 6.1 (Acciones para dirigir riegos y oportunidades) no se presentan cambios. La cláusula 6.2 (Objetivos de seguridad de la información y planificación para alcanzarlos) solo agrega que los objetivos deben ser monitoreados y estar disponibles como información documentada (lo que no se expresaba explícitamente en la edición anterior). Además, se agrega el requisito 6.3 (Planificación de cambios), que establece la ejecución planificada de cambios cuando la organización identifique la necesidad de modificaciones en el SGSI.

En este sentido, las metodologías de evaluación de riesgos utilizadas en procesos de operación del SGSI previos a la publicación de esta nueva edición del estándar, mantienen su vigencia.

La séptima cláusula (Soporte) define los elementos que respaldan la ejecución de las actividades planeadas. Entre estos factores se enlistan los recursos, competencias, concientización y comunicación, así como los requisitos de documentación para el sistema de gestión. El único cambio en esta sección es la eliminación del punto para incluir los procesos mediante los cuales se efectuará la comunicación relevante del SGSI en el requisito 7.4 (Comunicación).

La octava cláusula (Operación) solo presenta cambios de redacción y presentación en el requisito 8.1 (Planeación y control operacional) para modificar la referencia a los requisitos de la cláusula 6 y hacer énfasis en la necesidad de establecer criterios para los procesos e implementar el control de los procesos de acuerdo con los criterios descrito en dicha cláusula. Además, se considera que la información documentada deberá estar disponible en la medida necesaria para tener confianza en que los procesos se han llevado a cabo según lo planeado.

La novena cláusula (Evaluación del desempeño) considera las actividades para monitorear, medir, analizar y evaluar el sistema de gestión. También, considera los requisitos relacionados con las auditorías internas y la revisión por parte la dirección sobre el estado del sistema. El requisito 9.1 (Monitorear, medir, analizar y evaluar) únicamente presenta cambios de redacción, mientras que el requisito 9.2 (auditoría interna) presenta un cambio en su estructura para enfatizar las etapas en la ejecución del proceso de auditoría, del mismo modo que el requisito 9.3 (Revisión de gestión) que se presenta de un modo más estructurado.

Finalmente, la décima cláusula (Mejora) abarca los elementos necesarios para las acciones orientadas a corregir desviaciones con relación a lo que establece el estándar o para actividades de mejora relacionada con los controles de seguridad implementados. Los cambios en esta sección son solo de orden de presentación, apareciendo en primer lugar el requisito 10.1 (Mejora continua) y posteriormente el 10.2 (No conformidades y acción correctiva), sin alterar el contenido de estos.

Fuente: www.welivesecurity.com

Repasamos los cambios en la última versión de la ISO 27001, el estándar que define los requisitos para establecer, implementar, mantener y darle continuidad a la gestión de la seguridad de una organización.

La tecnología avanza y de forma inherente va dando lugar a nuevos riesgos determinados por las amenazas y las vulnerabilidades. Continuamente se desarrollan nuevas amenazas informáticas con características cada vez más ofensivas, al tiempo que cada vez se identifican más vulnerabilidades. A su vez, esto determina las tendencias, condiciones y necesidades en el ámbito de la seguridad de la información.

Teniendo esto en cuenta, factores externos como los nuevos modelos de negocio, la pandemia o los conflictos geopolíticos, también han tenido incidencia directa, por lo que es necesario renovar los controles de seguridad. En este contexto, los estándares de seguridad se revisan y actualizan periódicamente. Recientemente se presentó la nueva versión de ISO 27001 (ISO/IEC 27001:2022), una de las principales referencias en materia de ciberseguridad a nivel internacional.

¿Qué cambios presenta la versión 2022 de la ISO 27001?

Hacia finales de 2022 se publicó la ISO/IEC 27001:2022. Esta nueva versión de la ISO presenta cambios importantes en la cantidad y la forma de clasificar los controles de seguridad, además de modificaciones poco significativas en las cláusulas que definen los requisitos para establecer, implementar, operar, monitorear, revisar, mantener y mejorar un Sistema de Gestión de Seguridad de la Información (SGSI).

Los detalles de la implementación de cada uno de los controles considerados en ISO/IEC 27001 se pueden encontrar en la versión más reciente de ISO/IEC 27002, documento conocido en versiones anteriores como “código de prácticas”, que continúa siendo una guía de implementación. Este último documento también fue actualizado durante 2022, cambiando de título a “Information security, cybersecurity and privacy protection — Information security controls”, junto con su estructura para utilizar una taxonomía simple. Además, algunos controles se fusionaron, algunos se eliminaron y otros nuevos se han agregado.

Vale la pena recordar que mientras que la ISO 27001 establece los objetivos que debe cumplir una organización para obtener la certificación, la ISO 27002 establece los controles que son necesarios para cumplir con los objetivos.

A partir de los cambios en ISO/IEC 27002:2022, a continuación, repasamos los cambios en el Anexo A de ISO/IEC 27001:2022.

Se destaca que estas nuevas versiones de los documentos consideran dos nuevos aspectos: temas y atributos. Los temas hacen referencia a la forma de categorizar los controles de seguridad, que podría equipararse a los dominios utilizados en las ediciones pasadas. De esta manera, es posible encontrar cuatro temas o formas de clasificación: controles para personas, físicos, tecnológicos y organizacionales. Por otro lado, los atributos hacen referencia a otra forma de clasificación basados en otras perspectivas o enfoques, de tal manera que los atributos puedan ser utilizados para filtrar, ordenar o presentar los diferentes controles para distintos tipos de audiencias.

Existen cinco tipos de atributos: basado en el tipo de control (preventivo, detectivo o correctivo), propiedades de seguridad de la información (confidencialidad, integridad y disponibilidad), conceptos de ciberseguridad (identificar, proteger, detectar, responder y recuperar), capacidades operativas (capacidades de seguridad desde la perspectiva de los profesionales o practicantes, como la gobernanza o seguridad física) y dominios de seguridad (gobernanza y ecosistema, protección, defensa y resiliencia).

Además, el nuevo estándar reduce a 93 el número de controles de seguridad. De este modo, es posible identificar 8 controles para personas, 14 controles físicos, 34 controles tecnológicos y 37 controles organizacionales. Destaca también que los objetivos de control, identificados como los enunciados que describen lo que se desea alcanzar como resultado de la implementación de controles, ya no son considerados en la nueva edición.

Imagen 1. Controles de seguridad en las versiones de ISO/IEC 27001.

La reducción en la cantidad de controles se debe a la reorganización y fusión de algunos de los mismos. En la ISO 27001:2022 se presentan 11 nuevos controles de seguridad que atienden las necesidades de protección para las tendencias y nuevos enfoques de ciberseguridad: inteligencia de amenazas, seguridad de la información para el uso de servicios en la nube, preparación de las TIC para la continuidad del negocio, monitoreo de la seguridad física, gestión de la configuración, eliminación de información, enmascaramiento de datos, prevención de fuga de datos, actividades de monitoreo, filtrado Web y codificación segura.

Consideraciones en la selección e implementación de controles

Recordemos que los controles son definidos como medidas que tienen como propósito mantener y/o modificar los riesgos asociados a la información y otros activos. Sin embargo, es probable que los controles no siempre ejerzan el efecto de modificación deseado, por lo que deben ser revisados y actualizados constantemente para cumplir con las expectativas de protección basadas en los criterios de riesgo (aversión o propensión).

Además, las organizaciones no están sujetas ni obligadas a la implementación de todos los controles definidos en el estándar, pero la omisión de alguno de ellos debe ser documentada y justificada en la Declaración de Aplicabilidad (SoA); generalmente, la selección de los controles está determinada principalmente por los resultados de la evaluación de riesgos.

Finalmente, es importante recordar que las organizaciones pueden seleccionar e implementar controles o contramedidas para proteger sus activos basadas en otras fuentes de información y otros marcos de trabajo de ciberseguridad o seguridad de la información, y que las buenas prácticas recomendadas en el estándar deben ser adoptadas, adaptadas y aplicadas con base en las características, necesidades y condiciones de cada organización.

Fuente: www.welivesecurity.com

Con una semana de retraso con respecto a lo inicialmente planeado, Linus Torvalds ha anunciado el lanzamiento de Linux 4.18, una nueva versión del núcleo que no rompe con la tónica a la que nos tienen acostumbrados y llega repleta de novedades.

Como también es habitual, la ingente cantidad de cambios de cada versión de Linux nos hace enfocarnos solo en las novedades más destacadas, entre las cuales se encuentra el principio de soporte para el SoC Qualcomm Snapdragon 845, que ya está presente en diferentes dispositivos Android, pero cuyos controladores comienzan a integrarse ahora en el kernel. A nivel periféricos quizás lo más llamativo sea el soporte del Steam Controller, por lo que supuestamente ni siquiera sería necesario instalar Steam para disponer de plena funcionalidad con este recomendable mando de juegos.

En el apartado gráficos se mencionan cambios varios, incluyendo con soporte para las Vega M que integran las CPU Intel Kabylake-G, soporte inicial para las próximas Vega 20 y NVIDIA Quadro GV100 que aún están en desarrollo, para Intel Ice Lake, y mejoras en AMDGPU; así como mejoras generales en los controladores.

Linux 4.18 incluye asimismo cambios importantes relacionados con la seguridad, destacando las mitigaciones contra Spectre, la vulnerabilidad por diseño que asola muchas de las CPU modernas: para x86 se cubre la variante más reciente (la cuarta) y para ARM 32-bit las dos primeras. Otro cambio relacionado con la seguridad es la mejora del soporte de FUSE para permitir el montaje de unidades seguras y sin privilegios mediante una opción explícita, esto es, facilitando el montaje de sistemas de archivos a través de FUSE en el espacio de usuario y aislando al kernel de cualquier vulnerabilidad que les afectase.

Pero lo que más ha dado de qué hablar en las última fechas es Speck, un nuevo algoritmo de cifrado dirigido en principio a dispositivos IoT cuya novedad para esta versión es la compatibilidad completa con fscrypt, la biblioteca sobre la que se despliega el cifrado en disco.

Speck, creado para ofrecer un cifrado de bloques ligero en dispositivos con poca potencia, ha generado controversia al tratarse de un proyecto de la NSA, esa organización cándida que no siempre se ha acercado a Linux con los mejores propósitos, pero que lleva contribuyendo con el desarrollo del kernel desde hace bastante tiempo. Sin embargo, la controversia no surge tanto de las suspicacias que suscita la agencia estadounidense, pues sus aportaciones son abiertas y están sujetas a revisión, sino de la “debilidad” intrínseca que supone Speck.

Speck se integró en Linux 4.17 y desde entonces se anda debatiendo su suficiencia. Se cuenta que fue rechazo por ISO, pero que ha terminado en el núcleo por insistencia de Google, que estaría pensando en ello para terminales Android de gama baja. En It’s FOSS hace un buen repaso del devenir de los acontecimientos en torno a Speck e incluso dan las instrucciones para deshabilitarlo, aunque no es algo que sea necesario realizar en sistemas personales.

Ahora bien, lo verdaderamente sorprendente de la inclusión de Speck como módulo del kernel es que entró en la versión anterior y recibe más soporte en esta, pero al parecer Google habría decidido prescindir de ello y podría retirarse en las versiones próximas. Ver para creer.

Todo lo anterior y mucho más es lo que trae Linux 4.18, pero a falta de que en Kernel Newbies actualicen las notas de lanzamiento, lo que queda es una extensa lista de cambios aceptados.

Fuente:www.muylinux.com