ISO 27002:2022 – Control 8.28 – Codificación Segura

¿Qué es el Control 27002 de la norma ISO 2022:8.28 sobre codificación segura?

Las malas prácticas de codificación, como la validación de entradas inadecuada y la generación de claves débiles, pueden exponer los sistemas de información a vulnerabilidades de seguridad y provocar ciberataques y comprometer activos de información confidencial.

Por ejemplo, en el infame Incidente del error Heartbleed, los piratas informáticos aprovecharon la validación de entrada incorrecta en el código para obtener acceso a más de 4 millones de datos de pacientes.

Por lo tanto, las organizaciones deben garantizar que se sigan los principios de codificación segura para que las prácticas de codificación deficientes no generen vulnerabilidades de seguridad.

Propósito del Control 8.28

Control 8.28 permite a las organizaciones prevenir riesgos y vulnerabilidades de seguridad que pueden surgir como resultado de prácticas deficientes de codificación de software mediante el diseño, implementación y revisión de principios apropiados de codificación de software seguro.

Tabla de Atributos de Control 8.28

Control 8.28 es un tipo de control preventivo que ayuda a las organizaciones a mantener la seguridad de redes, sistemas y aplicaciones eliminando los riesgos que pueden surgir de un código de software mal diseñado.

Propiedad del Control 8.28

Teniendo en cuenta que 8.28 requiere el diseño y la implementación de principios y procedimientos de codificación segura en toda la organización, el director de seguridad de la información debe ser responsable de tomar las medidas adecuadas para su cumplimiento.

Orientación general sobre cumplimiento

El Control 8.28 requiere que las organizaciones establezcan e implementen procesos en toda la organización para la codificación segura que se aplique tanto a productos de software obtenidos de partes externas como a componentes de software de código abierto.

Además, las organizaciones deben mantenerse actualizadas con la evolución de las amenazas a la seguridad del mundo real y con la información más reciente sobre vulnerabilidades de seguridad del software conocidas o potenciales. Esto permitirá a las organizaciones mejorar e implementar principios sólidos de codificación de software seguro que sean efectivos contra las amenazas cibernéticas en evolución.

Orientación complementaria sobre planificación

Se deben seguir los principios de codificación de software seguro tanto para nuevos proyectos de codificación como para operaciones de reutilización de software.

Estos principios deben respetarse tanto para las actividades internas de desarrollo de software como para la transferencia de los productos o servicios de software de la organización a terceros.

Al establecer un plan para los principios de codificación segura y determinar los requisitos previos para la codificación segura, las organizaciones deben cumplir con lo siguiente:

• Las organizaciones deben determinar expectativas de seguridad adaptadas a sus necesidades y establecer principios aprobados para la codificación de software segura que se aplicarán tanto al desarrollo de software interno como a los componentes de software subcontratados.
• Las organizaciones deben detectar y documentar los errores y prácticas de diseño de codificación deficientes más frecuentes e históricos que ponen en peligro la seguridad de la información.
• Las organizaciones deben implementar y configurar herramientas de desarrollo de software para garantizar la seguridad de todo el código creado. Un ejemplo de este tipo de herramientas son los entornos de desarrollo integrados (IDE).
• Las organizaciones deben lograr el cumplimiento de las orientaciones e instrucciones proporcionadas por las herramientas de desarrollo de software.
• Las organizaciones deben revisar, mantener y utilizar de forma segura herramientas de desarrollo como los compiladores.

Orientación complementaria sobre seguridad durante la codificación

Las prácticas y procedimientos de codificación segura deben tener en cuenta lo siguiente para el proceso de codificación:

• Los principios de codificación de software seguro deben adaptarse a cada lenguaje y técnica de programación utilizados.
• Implementación de técnicas y métodos de programación segura, como el desarrollo basado en pruebas y la programación por pares.
• Uso de métodos de programación estructurada.
• Documentación adecuada del código y eliminación de defectos del código.
• Prohibición del uso de métodos de codificación de software inseguros, como muestras de códigos no aprobados o contraseñas codificadas.

La Guía complementaria también señala que las pruebas de seguridad deben realizarse tanto durante como después del desarrollo de acuerdo con el Control 8.29.

Antes de poner el software en uso real en el entorno de aplicaciones en vivo, las organizaciones deben considerar lo siguiente:

• ¿Cuál es la superficie de ataque?
• ¿Se sigue el principio de privilegio mínimo?
• Realizar un análisis de los errores de programación más frecuentes y documentar que estos riesgos han sido eliminados.

Orientación complementaria sobre el proceso de revisión

Después de que el código se ponga en uso en el entorno de producción

• Las actualizaciones deben aplicarse de forma segura.
• Deben abordarse las vulnerabilidades de seguridad informadas de acuerdo con el Control 8.8.
• Los ataques sospechosos a los sistemas de información y los errores deben registrarse y estos registros deben revisarse a intervalos regulares para que se puedan realizar los cambios apropiados en el código.
• El acceso no autorizado, el uso o los cambios en el código fuente deben evitarse mediante mecanismos como herramientas de gestión.

Cuando las organizaciones utilizan herramientas externas, deben tener en cuenta lo siguiente

• Las bibliotecas externas deben monitorearse y actualizarse periódicamente según sus ciclos de lanzamiento.
• Los componentes de software deben examinarse, seleccionarse y autorizarse cuidadosamente, especialmente los componentes de criptografía y autenticación.
• Licencia de componentes externos y garantía de su seguridad.
• El software debe ser rastreado y mantenido. Además, hay que asegurarse de que procede de una fuente fiable.
• Los recursos para el desarrollo deben estar disponibles para el largo plazo.

Al realizar cambios en un paquete de software, se debe considerar lo siguiente

• Riesgos que pueden surgir de controles incorporados o del compromiso de los procesos de integridad.
• Si el proveedor da su consentimiento a los cambios.
• Si es posible obtener el consentimiento del proveedor de software para realizar actualizaciones periódicas.
• El impacto probable de continuar con el mantenimiento del software que surge de los cambios.
• Si los cambios serían compatibles con otros componentes de software utilizados por la organización.

Orientación adicional sobre control 8.28

Las organizaciones deben garantizar que se utilice código relevante para la seguridad cuando sea necesario y que sea resistente a la manipulación.

Control 8.28 también enumera las siguientes recomendaciones para código relevante para la seguridad:

• Si bien los programas instalados mediante código binario incluyen código relevante para la seguridad, esto se limita a los datos almacenados dentro de la propia aplicación.
• El concepto de código relevante para la seguridad solo es útil cuando el código se ejecuta en un servidor al que no puede acceder el usuario y está segregado de los procesos que lo utilizan y sus datos se guardan de forma segura en otra base de datos. Por ejemplo, puede ejecutar un código interpretado en un servicio en la nube y el acceso al código puede restringirse a administradores privilegiados. Se recomienda proteger estos derechos de acceso mediante métodos como privilegios de administrador puntuales y mecanismos de autenticación sólidos.
• Se deben implementar configuraciones adecuadas en los servidores web para evitar el acceso no autorizado y la navegación en el directorio.
• Al diseñar el código de una aplicación, debe comenzar asumiendo que el código es vulnerable a ataques debido a errores de codificación y acciones de actores malintencionados. Debe diseñar aplicaciones críticas de manera que no sean vulnerables a fallas internas. Por ejemplo, el resultado producido por un algoritmo se puede revisar para garantizar que cumple con los requisitos de seguridad antes de que pueda usarse en aplicaciones críticas, como aplicaciones relacionadas con finanzas.
• Ciertas aplicaciones web son muy vulnerables a las amenazas a la seguridad debido a prácticas de codificación deficientes, como la inyección de bases de datos y los ataques de secuencias de comandos entre sitios.
• Las organizaciones deben consultar la serie ISO/IEC 15408 para obtener más información sobre la evaluación de la seguridad de TI.

Cambios y diferencias con respecto a ISO 27002:2013

27002:2022/8.28 es un nuevo tipo de control.

Nuevos controles ISO 27002

Cómo ayuda ISMS.online

Nuestra plataforma ha sido desarrollada específicamente para aquellos que son nuevos en la seguridad de la información o necesitan una manera fácil de aprender sobre ISO 27002 sin tener que perder tiempo aprendiendo desde cero o leyendo documentos extensos.

ISMS.Online viene equipado con todas las herramientas necesarias para lograr el cumplimiento, incluidas plantillas de documentos, listas de verificación y políticas que se pueden personalizar según sus necesidades.

¿Quieres ver cómo funciona?

Ponte en contacto hoy para RESERVAR UNA DEMOSTRACIÓN.