ISO 27001 – Anexo A.14: Adquisición, desarrollo y mantenimiento del sistema

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

El anexo A.14.1 trata sobre los requisitos de seguridad de los sistemas de información. El objetivo en esta área del Anexo A es garantizar que la seguridad de la información sea una parte integral de los sistemas de información durante todo el ciclo de vida. Esto también incluye los requisitos para los sistemas de información que brindan servicios a través de redes públicas.

ISO 27001:2013 aborda el ciclo de vida desde A.14.1.1 a A.14.1.3 y 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.

A.14.1.1 Análisis y especificación de requisitos de seguridad de la información

Los requisitos relacionados con la seguridad de la información deben incluirse en cualquier requisito para nuevos sistemas de información o mejoras a los sistemas de información existentes. Esto puede suceder junto con A.6.1.5 como parte de la seguridad de la información en proyectos y debe tener en cuenta el valor de la información en riesgo que podría alinearse con el esquema de clasificación de información en A.8.2.1.

En cualquier desarrollo de un nuevo sistema o cambio en los sistemas existentes, es importante comprender cuáles son los requisitos comerciales para los controles de seguridad mediante una evaluación de riesgos. Esto debe hacerse antes de la selección o el comienzo del desarrollo de una solución. Las consideraciones de seguridad deben realizarse desde la primera oportunidad posible para garantizar que se identifiquen los requisitos correctos antes de comenzar la selección de la solución.

Los requisitos de seguridad deben documentarse y acordarse para que se pueda hacer referencia a ellos a medida que se adquiere o desarrolla la solución. No es una buena práctica seleccionar o desarrollar una solución y luego evaluar el nivel de capacidad de seguridad. Esto a menudo conduce a mayores riesgos y costos y también puede causar problemas en la legislación aplicable, como el GDPR, que fomenta una filosofía de diseño segura y técnicas como las Evaluaciones de Impacto de la Privacidad de la Protección de Datos (DPIA). También existen numerosos sitios web que defienden prácticas de desarrollo seguras y principios clave a tener en cuenta, como los que defiende el Centro Nacional de Seguridad Cibernética (NCSC). ISO 27002 también incluye orientación para la implementación. Cualquiera de los principios que se siguen deben documentarse.

El auditor observará que la seguridad se considere en todas las etapas del ciclo de vida de un proyecto, para un nuevo sistema o cambios en un sistema existente. También esperarán que se considere la confidencialidad, integridad y disponibilidad como mínimo antes de que comience el proceso de selección o desarrollo.

A.14.1.2 Protección de servicios de aplicaciones en redes públicas

La información involucrada en los servicios de aplicaciones que pasan a través de redes públicas debe protegerse contra actividades fraudulentas, disputas contractuales y revelaciones y modificaciones no autorizadas. Para los servicios que se brindan a través de una red pública, como Internet, es importante comprender los niveles de riesgo involucrados y los requisitos comerciales para proteger la información. Una vez más, es importante considerar la confidencialidad, la integridad y la disponibilidad.

Cuando las transacciones financieras o la información personal sensible forman parte del servicio, es especialmente importante considerar la seguridad para minimizar el riesgo de actividad fraudulenta donde los requisitos del RGPD para el cifrado y otras salvaguardas deben ser los requisitos mínimos. Una vez operativos, es importante garantizar que dichos servicios sean monitoreados constantemente para detectar ataques o actividades no deseadas. El auditor esperará que se considere “qué tan seguros” deben ser los servicios de aplicaciones a través de redes públicas, con decisiones basadas en la evaluación de riesgos y otros requisitos legales, regulatorios y contractuales.

A.14.1.3 Protección de las transacciones de servicios de aplicaciones

La información involucrada en las transacciones de servicios de aplicaciones debe protegerse para evitar transmisiones incompletas, enrutamientos incorrectos, alteraciones no autorizadas de mensajes, divulgación no autorizada, duplicación o reproducción no autorizada de mensajes. Es probable que una protección adicional asegure las transacciones de servicios de aplicaciones (no necesariamente solo transacciones financieras). Estos pueden incluir; Uso de firmas electrónicas, Uso de cifrado; y Uso de protocolos seguros. También es probable que sea necesario realizar un seguimiento continuo de dichas transacciones casi en tiempo real.

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

El Anexo A.14.2 trata sobre la seguridad en los procesos de desarrollo y soporte. El objetivo en esta área del Anexo A es garantizar que la seguridad de la información se diseñe e implemente dentro del ciclo de vida de desarrollo de los sistemas de información.

A.14.2.1 Política de desarrollo seguro

Se deben establecer y aplicar reglas para el desarrollo de software y sistemas a los desarrollos dentro de la organización. Se utiliza una política de desarrollo seguro para garantizar que los entornos de desarrollo sean seguros en sí mismos y que los procesos para desarrollar e implementar sistemas y cambios en los sistemas fomenten el uso de prácticas de desarrollo y codificación seguras.

Dichas políticas incluirán mostrar cómo se debe considerar la seguridad en todas las etapas del ciclo de vida del desarrollo, desde el diseño hasta la implementación en vivo. Los lenguajes de codificación y las herramientas de desarrollo específicos tienen diferentes vulnerabilidades y requieren diferentes técnicas de "refuerzo" en consecuencia y es importante que se identifiquen y acuerden y que los desarrolladores sean conscientes de sus responsabilidades para seguirlas.

Las políticas de cumplimiento abordarán los puntos de control de seguridad durante el desarrollo; repositorios seguros; seguridad en el control de versiones; conocimiento de seguridad de aplicaciones; y la capacidad de los desarrolladores para evitar vulnerabilidades, luego encontrarlas y solucionarlas cuando ocurren. El auditor observará aquí para ver que las consideraciones de seguridad sean apropiadas para el nivel de riesgo de los sistemas que se están desarrollando o modificando y que quienes realizan el desarrollo comprendan la necesidad de incluir consideraciones de seguridad durante todo el ciclo de vida del desarrollo. Es esencial realizar una sólida evaluación inicial en la contratación de estas habilidades, la gestión en la vida y la capacitación de recursos, y prácticas como la programación en pareja, las revisiones por pares y el control de calidad independiente, las revisiones de códigos y las pruebas son todos atributos positivos.

A.14.2.2 Procedimientos de control de cambios del sistema

Los cambios en los sistemas dentro del ciclo de vida del desarrollo deben controlarse mediante el uso de procedimientos formales de control de cambios. Los procedimientos de control de cambios del sistema deben integrarse, estar alineados y respaldar el control de cambios operativos. Los procedimientos formales de gestión de cambios están diseñados para reducir el riesgo de desarrollo accidental o deliberado de vulnerabilidades que puedan permitir que los sistemas se vean comprometidos una vez que los cambios se implementen. Para el control de cambios del sistema, es importante que el propietario del sistema comprenda qué cambios se realizan en su sistema, por qué y quién. Es su responsabilidad garantizar que sus sistemas no se vean comprometidos debido a un desarrollo deficiente o malicioso.

Por lo tanto, deberían participar en el establecimiento de las normas de autorización y de pruebas y controles previos al funcionamiento. Se requieren registros de auditoría para proporcionar evidencia del uso correcto de los procedimientos de cambio. ISO 27002 documenta muchos aspectos del control de cambios que deben incluirse, desde la simple documentación de los cambios hasta la consideración del tiempo de implementación para evitar un impacto negativo en el negocio. Este control, como otros en A.14, también se alinea con los procedimientos documentados en A.12.1.2.

A.14.2.3 Revisión técnica de aplicaciones después de cambios en la plataforma operativa

Cuando se cambian las plataformas operativas, las aplicaciones críticas para el negocio deben revisarse y probarse para garantizar que no haya un impacto adverso en las operaciones o la seguridad de la organización. Cuando se cambian las plataformas del sistema operativo es común que algunas aplicaciones puedan tener problemas de compatibilidad. Por lo tanto, es importante probar los cambios del sistema operativo en un entorno de desarrollo o prueba donde se pueda verificar la compatibilidad de las aplicaciones comerciales críticas con el sistema operativo modificado. Los procedimientos para el control y prueba de cambios en el sistema operativo deben seguir el control estándar de gestión de cambios.

A.14.2.4 Restricciones sobre cambios en paquetes de software

Es necesario desalentar las modificaciones de los paquetes de software, limitarlas a los cambios necesarios y todos los cambios deben controlarse estrictamente. Los paquetes de software proporcionados por los proveedores están diseñados para el mercado masivo y en realidad no están diseñados para organizaciones que realizan sus propios cambios en ellos. De hecho, la mayoría de las veces el proveedor bloquea la posibilidad de realizar dichos cambios y la personalización se limita al paquete. Cuando se utiliza software de código abierto, es mucho más probable que la organización pueda realizar cambios; sin embargo, esto debe restringirse y controlarse para garantizar que los cambios realizados no tengan un impacto adverso en la integridad interna o la seguridad de la organización. software.

A.14.2.5 Principios de ingeniería de sistemas seguros

Se deben establecer, documentar, mantener y aplicar principios para diseñar sistemas seguros a cualquier esfuerzo de implementación de sistemas de información. Los principios de ingeniería de software seguro existen tanto a nivel general como específico para plataformas de desarrollo y lenguajes de codificación. Dondequiera que se lleve a cabo el desarrollo, se debe considerar, evaluar, documentar formalmente y exigir la consideración para la selección y aplicación de dichos principios. El auditor querrá ver que, como ocurre con muchos controles, el uso de principios de ingeniería de sistemas se considera en comparación con los niveles de riesgo identificados y buscará evidencia que respalde las decisiones tomadas.

A.14.2.6 Entorno de desarrollo seguro

Las organizaciones necesitan establecer y proteger adecuadamente entornos de desarrollo seguros para los esfuerzos de desarrollo e integración de sistemas que cubran todo el ciclo de vida de desarrollo del sistema. Los entornos de desarrollo deben protegerse para garantizar el desarrollo y la actualización maliciosa o accidental de código que pueda crear vulnerabilidades o comprometer la confidencialidad, la integridad y la disponibilidad. Los requisitos de protección deben determinarse a partir de la evaluación de riesgos, los requisitos comerciales y otros requisitos internos y externos, incluida la legislación, la regulación, los acuerdos contractuales o las políticas. En particular, si se utiliza algún tipo de datos en vivo en entornos de desarrollo, es necesario protegerlos y controlarlos especialmente.

A.14.2.7 Desarrollo subcontratado

La organización debe supervisar y monitorear la actividad de desarrollo de sistemas subcontratados. Cuando el desarrollo de sistemas y software se subcontrata total o parcialmente a partes externas, los requisitos de seguridad deben especificarse en un contrato o acuerdo adjunto. Aquí es donde es importante tener correcto el Anexo A 15.1, así como el A.13.2.4 sobre no divulgación y confidencialidad.

También es importante supervisar y monitorear el desarrollo para garantizar que se cumplan los estándares y requisitos organizacionales de seguridad dentro de los sistemas. Dependiendo de qué tan integrados estén los socios subcontratados dentro de la organización, especialmente si el personal está ubicado en las instalaciones de la organización, es importante incluir a su personal en la capacitación sobre concientización sobre seguridad y en los programas y comunicaciones de concientización. Es fundamental garantizar que las prácticas de seguridad interna del socio subcontratado, por ejemplo, la investigación de antecedentes del personal, cumplan al menos con los requisitos de garantía relevantes para los niveles de riesgo relacionados con los desarrollos en los que trabajarán.

El auditor observará que, cuando se utiliza la subcontratación, exista evidencia de diligencia debida antes, durante y después de que se haya llevado a cabo la contratación del socio subcontratado e incluya la consideración de disposiciones de seguridad de la información.

A.14.2.8 Pruebas de seguridad del sistema

Es necesario realizar pruebas de la funcionalidad de seguridad durante el desarrollo. Las pruebas específicas de la funcionalidad de seguridad para cualquier desarrollo deben ser realizadas y aprobadas por una autoridad apropiada con competencia y responsabilidad en materia de seguridad. Los resultados esperados de las pruebas de seguridad deben documentarse antes de que comiencen las pruebas y deben basarse en los requisitos de seguridad del negocio. El auditor querrá comprobar que existe evidencia de que se han realizado pruebas específicas de seguridad en cualquier desarrollo que sea relevante para la seguridad.

A.14.2.9 Prueba de aceptación del sistema

Se deben establecer programas de pruebas de aceptación y criterios relacionados para nuevos sistemas de información, actualizaciones y nuevas versiones. Para las pruebas de aceptación, las pruebas y los criterios para demostrar una prueba exitosa deben diseñarse y desarrollarse en función de los requisitos comerciales antes de realizar las pruebas. Las pruebas de aceptación también deben incluir pruebas de seguridad. El auditor buscará evidencia que demuestre que los criterios y métodos de las pruebas de aceptación se diseñaron de acuerdo con los requisitos comerciales e incluyen disposiciones para las pruebas de aceptación de seguridad.

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

El anexo A.14.3 trata sobre datos de prueba. El objetivo en esta área del Anexo A es garantizar la protección de los datos utilizados para las pruebas.

A.14.3.1 Protección de los datos de prueba

Los datos de prueba deben seleccionarse, protegerse y controlarse cuidadosamente. Lo ideal es que los datos de prueba se creen en un formato genérico sin relación con los datos del sistema en vivo. Sin embargo, se reconoce que a menudo se deben utilizar datos en vivo para realizar pruebas precisas. Cuando se utilizan datos en vivo para pruebas, debería ser así; Anonimizado en la medida de lo posible; Seleccionados cuidadosamente y asegurados para el período de prueba; Se elimina de forma segura cuando se completa la prueba. El uso de datos en vivo debe ser autorizado previamente, registrado y monitoreado. El auditor esperará ver procedimientos sólidos implementados para proteger los datos que se utilizan en entornos de prueba, especialmente si se trata de datos total o parcialmente activos.

Puede encontrar más ayuda sobre los requisitos de ISO 27001 y los controles del Anexo A en el Entrenador virtual en línea de ISMS.online que complementa nuestros marcos, herramientas y contenido de políticas.