Ningún procesamiento de datos e información puede realizarse sin software. El desarrollo de software se centra principalmente en el funcionamiento de algoritmos para tareas específicas. Sin embargo, ahora es bien conocido que una mala escritura del código de un programa a menudo también da lugar a problemas de seguridad, como controles de acceso defectuosos, inyección de SQL, gestión y autenticación de sesiones incorrectas, scripts entre sitios, etc.

La gran importancia de las prácticas de codificación segura se destaca en los estándares actualizados de seguridad de la información ISO/IEC 27002 e ISO/IEC 27001:2022. Como nueva medida de seguridad de la información (control), los principios de "Codificación Segura" en el desarrollo de software están ingresando al catálogo de medidas del Anexo A de ISO/IEC 27001. Lea sobre la importancia de esta medida para la seguridad de su información y lo que significa para futuras auditorías en nuestra publicación de blog.

Vulnerabilidades de seguridad en el código.

El software del sistema operativo, el software de aplicación o el firmware de un sistema integrado son componentes elementales de cualquier infraestructura digital. Sin embargo, la creciente aceleración y la presión de los plazos en los proyectos de digitalización a menudo conducen a que se descuiden aspectos imperativos de seguridad de la información. Los requisitos de desarrollo de software suelen centrarse en las funciones y enfatizan los aspectos constructivos, de modo que la visión destructiva de las posibles vulnerabilidades de seguridad es diametralmente opuesta a los objetivos reales del desarrollo: muchos programadores simplemente carecen de una visión estructurada y precisa de la ciberseguridad.

En estas condiciones, los equipos de desarrollo tienen dificultades para revisar continuamente y asegurar consistentemente la codificación de su software, como lo demuestran las numerosas vulnerabilidades que la organización sin fines de lucro MITRE Corporation publica cada año en su CVE (Vulnerabilidades y exposiciones comunes). Los parches de seguridad regulares, incluso de los fabricantes de software más conocidos, son un indicador de la difícil tarea de corregir errores relevantes para la seguridad, y mucho menos identificarlos incluso antes de su lanzamiento al mercado.

Código fuente abierto: un caso especial

Al codificar software de desarrollo propio, a los programadores les gusta recurrir a bibliotecas y módulos de código abierto. Las ventajas prácticas son obvias: si no tiene que reinventar la rueda una y otra vez, se beneficiará de este impulso tecnológico, un desarrollo rápido, menores costos de desarrollo, más transparencia a través del código fuente abierto y una mayor interoperabilidad a través de estándares e interfaces abiertos. .

También se suele decir que el código de código abierto ofrece un alto grado de seguridad porque el código ha sido validado por muchos usuarios y la inteligencia de enjambre de la comunidad de código abierto permite una corrección de errores rápida y eficiente.

En la práctica, esta confianza debe evaluarse ahora de manera diferenciada y crítica. El ejemplo más grave es la vulnerabilidad de seguridad de día cero Log4Shell en la biblioteca de registro ampliamente utilizada Log4J para aplicaciones Java, que se descubrió en noviembre de 2021. Es posible que haya oído hablar del nivel de alerta roja emitido por la Oficina Federal Alemana de Seguridad de la Información (BSI). ) para Log4Shell. La biblioteca Log4J, distribuida como cuasi estándar y que funciona de forma fiable a través de la Fundación Apache, se ha consolidado desde 2013 en muchos sistemas, incluidos servicios web conocidos como Amazon AWS.

La complejidad de estas bibliotecas bien desarrolladas y mantenidas proporciona implícitamente potentes funcionalidades que un desarrollador importador a menudo desconoce en su propio nuevo desarrollo combinado, pero que pueden ser explotadas por los atacantes.

Otro factor de inseguridad de los componentes de código abierto son los llamados ataques a la cadena de suministro, es decir, vulnerabilidades integradas intencionadas por parte de actores maliciosos que se hacen pasar por parte de la comunidad de código abierto y ayudan en el desarrollo de código. Esta vulnerabilidad es una forma extremadamente eficiente para que los piratas informáticos ataquen a una gran cantidad de organizaciones de usuarios intermedios. No es de extrañar, entonces, que este vector de ataque esté creciendo rápidamente: estudio sonatipo diagnosticó un aumento del 650% al comparar 2020 y 2021.

whitepaper-ISO 27001-faq-dqs-cover picture
Loading...

Preguntas frecuentes sobre ISO/IEC 27001:2022

"El Nuevo" para la Seguridad de la Información: 38 Preguntas y Respuestas

Lo que necesita saber sobre el "nuevo chico de la cuadra" en materia de seguridad de la información: 38 respuestas de nuestros expertos a 38 preguntas de usuarios .

¿De qué se tratan los nuevos controles?

  • ¿Cuándo deberíamos hacer la transición al nuevo estándar?
  • ¿Dónde puedo encontrar una lista de correspondencias antiguas y nuevas?
  • ... ¡y 35 más!

Control de seguridad de la información 8.28 codificación segura

Para salvaguardar el proceso de desarrollo de software en tiempo y forma, la Organización Internacional de Normalización (ISO - comité ISO/IEC JTC 1/SC 27) ha incluido "Codificación segura" como nuevo control 8.28 en la nueva ISO/IEC 27002 y ISO/CEI 27001:2022 , Normas del Anexo A. La finalidad de la medida técnica de codificación segura es la protección preventiva del software.

Ya en la fase de redacción se crea un nivel mínimo de seguridad basándose en normas de procedimiento, minimizando así el número de posibles vulnerabilidades de seguridad en el software. El marco regulatorio para la generación segura de códigos debe aplicarse de manera integral tanto al código de programa propio como al software de terceros y de fuentes abiertas. Los principios notables para la implementación son Seguridad por diseño y Mínimo Privilegio, que también debe considerarse en la codificación.

Principios de codificación segura

La medida 8.28 aborda varias veces los llamados principios de codificación segura. Numerosas organizaciones e institutos que publican periódicamente guías y mejores prácticas para la codificación segura proporcionan orientación sobre cuáles podrían ser. Estos incluyen, por ejemplo, el Prácticas de codificación segura de la Fundación OWASP, la Estándares de codificación segura de el Equipo de Respuesta a Emergencias Informáticas (CERT) del Instituto de Ingeniería de Software (SEI), y el catálogo de medidas para la seguridad de aplicaciones web del BSI alemán. A pesar de las diferentes fuentes, las elaboraciones muestran muchos paralelos, por ejemplo en lo que respecta a los siguientes puntos:

  • Validación de entrada de datos.
  • Seguridad de la autenticación y la gestión de contraseñas
  • Control de acceso seguro
  • Código simple y transparente
  • Medidas y componentes criptográficos probados de forma sostenible
  • Manejo de errores y registro
  • Protección de Datos
  • Modelado de amenazas

En la norma ISO/ISO 27002:2022, las acciones recomendadas para el Control 8.28 se dividen en tres secciones, "Planificación y precodificación", "Durante la codificación" y "Verificación y mantenimiento", cuyos contenidos principales se describen a continuación.

webinar-dqs-junger-mann-mit-headset-sitzt-vor-einem-laptop
Loading...

Míralo ahora: Qué cambia con la nueva ISO/IEC 27001:2022

La nueva versión de ISO/IEC 27001, adaptada a los riesgos de la información contemporánea, se publicó el 25 de octubre de 2022. ¿Qué significa esto para los usuarios de la norma? En nuestro grabación de seminarios web gratuitos , aprenderás sobre

  • Nuevas características de ISO/IEC 27001:2022 - Marco y Anexo A
  • ISO/IEC 27002:2022-02 - estructura, contenido, atributos y hashtags
  • Cronograma para la transición y sus próximos pasos

Planificación y precodificación

Tanto el desarrollo de código nuevo como la reutilización de código requieren la aplicación de principios de codificación segura, independientemente de si el código está escrito para software interno o para productos y servicios externos. Esto requiere una evaluación previa de las expectativas específicas de la organización y la definición de principios reconocidos. Además, las acciones recomendadas para la planificación y la precodificación tienen en cuenta las prácticas y errores de codificación históricos y comunes conocidos que podrían generar vulnerabilidades.

La configuración de herramientas de desarrollo, como las basadas en reglas en entornos de desarrollo integrados (IDE), debería exigir la creación de código seguro. Es muy importante la cualificación de los desarrolladores y su familiaridad con las arquitecturas seguras y los estándares de programación. La inclusión de experiencia en seguridad de la información en el equipo de desarrollo es evidente.

Durante el proceso de codificación

Durante el proceso de codificación, las prácticas de codificación y las técnicas de programación estructurada desempeñan un papel primordial, teniendo en cuenta el caso de uso específico y sus necesidades de seguridad. Las técnicas de diseño inseguras (por ejemplo, contraseñas codificadas) deberían prohibirse sistemáticamente. El código debe documentarse y revisarse adecuadamente para eliminar mejor los errores relacionados con la seguridad. La revisión del código debe realizarse tanto durante como después del desarrollo, mediante pruebas de seguridad de aplicaciones estáticas (SAST) o similares. Los métodos de pruebas estáticas respaldan el enfoque de desplazamiento a la izquierda ("probar temprano y con frecuencia") al desplazarse hacia la izquierda en el ciclo de vida al probar el código visible para determinar la conformidad con las reglas de manera temprana.

Esto permite la identificación temprana de código contaminado, conexiones a archivos o clases de objetos específicos, o brechas a nivel de aplicación de las que se puede abusar para una interacción inadvertida con programas de terceros como vulnerabilidades explotables. Antes de poner en funcionamiento el software, Control 8.28 requiere una evaluación de las superficies de ataque y la implementación del principio de privilegio mínimo. Se debe evaluar el análisis realizado de los errores de programación más comunes y la documentación de su corrección.

Cyberattack - Bildschirm zeigt Zahlencodes mit Warnsignalen
Loading...

Esto también te puede interesar:

Detección y prevención en la gestión de la seguridad de la información.

Verificación y mantenimiento

Incluso después de que el software esté activo, el tema de la codificación segura sigue siendo relevante. Esto incluye actualizaciones seguras y comprobaciones de vulnerabilidades conocidas en el código. Además, se deben documentar los errores y los ataques sospechosos para que se puedan realizar los ajustes necesarios con prontitud. En cualquier caso, el acceso no autorizado al código fuente debe impedirse de forma fiable mediante herramientas adecuadas.

Código fuente abierto

En el área de verificación y mantenimiento, la Medida 8.28 enumera además instrucciones explícitas para el uso de herramientas y bibliotecas externas, como software de código abierto. Estos componentes del código deben gestionarse, actualizarse y mantenerse en inventarios. Esto se puede hacer, por ejemplo, mediante una lista de materiales de software (SBOM). Un SBOM es un registro formal y estructurado de los paquetes y bibliotecas de un software y sus relaciones entre sí y dentro de la cadena de suministro, en particular para realizar un seguimiento del código reutilizado y los componentes de código abierto. El SBOM admite la capacidad de mantenimiento del software y las actualizaciones de seguridad específicas.

fragen-antwort-dqs-fragezeichen auf wuerfeln aus holz auf tisch
Loading...

Certificación según ISO 27001

¿Qué esfuerzo tienes que realizar para tener tu SGSI certificado según ISO 27001? Obtenga información de forma gratuita y sin compromiso.

Esperamos hablar con usted.

Conclusión

El código seguro es una base elemental para detener posibles ataques. El nuevo Control 8.28 tiene en cuenta esta sufrida visión y actualiza el papel clave de la codificación segura en su importancia para la seguridad de la información. Sin embargo, dado que la medida incluye un gran número de recomendaciones de acción detalladas y es técnicamente exigente, su implementación requerirá un nivel de esfuerzo comparativamente alto; esto debería tenerse en cuenta ya en la fase de planificación.

Con la visión profesional de nuestros auditores experimentados, lo apoyamos en la implementación conforme de la medida. Con nuestra experiencia en auditoría y certificación de más de 35 años, somos su socio de contacto ideal y estaremos encantados de ayudarle en el tema de seguridad de la información y certificación según las normas ISO/IEC 27001:2022.

Revisión de ISO 27001: ¿Qué significa la actualización para su certificación?

ISO/IEC 27001:2022 se publicó el 25 de octubre de 2022. Esto da como resultado los siguientes plazos y plazos para la transición de los usuarios:

Última fecha para auditorías iniciales/recertificación según la "antigua" ISO 27001:2013

  • Después del 30 de abril de 2024, DQS realizará auditorías iniciales y de recertificación únicamente de acuerdo con la nueva norma ISO/IEC 27001:2022.

Transición de todos los certificados existentes según la "antigua" ISO/IEC 27001:2013 a la nueva ISO/IEC 27001:2022

  • Existe un período de transición de 3 años a partir del 31 de octubre de 2022.
  • Los certificados emitidos según ISO/IEC 27001:2013 o DIN EN ISO/IEC 27001:2017 son válidos hasta el 31 de octubre de 2025 a más tardar o deben retirarse en esta fecha.

DQS: Simplemente aprovechando la seguridad.

Debido a los periodos de transición, las empresas tienen tiempo suficiente para adaptar su SGSI a los nuevos requisitos y certificarlo. Sin embargo, no se debe subestimar la duración y el esfuerzo de todo el proceso de cambio, especialmente si no se cuenta con suficiente personal especializado. Si quiere estar seguro, debería solucionar el problema lo antes posible y, si es necesario, recurrir a especialistas experimentados.

Como expertos en auditoría y certificación con más de 35 años de experiencia, estaremos encantados de ayudarle a evaluar su estado actual, tal vez como parte de una auditoría delta. Infórmese con nuestros numerosos auditores experimentados sobre los cambios más importantes y su relevancia para su organización. Juntos discutiremos su potencial de mejora y lo apoyaremos hasta que reciba su nuevo certificado. ¡Aproveche nuestra competencia en seguridad de la información! Esperamos con interés escuchar de usted.

fragen-antwort-dqs-fragezeichen auf wuerfeln aus holz auf tisch
Loading...

Enviar Consulta

¡Contáctenos!

Sin compromiso y de forma gratuita.

Autor
Markus Jegelka

Experto en DQS para sistemas de gestión de seguridad de la información (ISMS) y auditor desde hace mucho tiempo para las normas ISO 9001, ISO/IEC 27001 y el catálogo de seguridad de TI según el apartado 11.1a/b de la Ley alemana de la industria energética (EnWG) con competencia en procedimientos de prueba para § Artículo 8a (3) BSIG

 

Loading...