Buenas prácticas para desarrollo de software seguro

1. Introducción

En un mundo cada vez más digitalizado, la seguridad del software se ha convertido en una preocupación primordial. Las amenazas cibernéticas son cada vez más sofisticadas y frecuentes, lo que exige un enfoque riguroso y proactivo al desarrollar software aportando un enfoque que aporte seguridad al proceso. Actualmente los enfoques para garantizar la seguridad y privacidad en el desarrollo de software, se centran en dos vertientes que convergen: privacidad por diseño y seguridad por diseño. Ambos enfoques son críticos para crear sistemas de información robustos que no solo protejan contra amenazas externas, sino que también respeten y salvaguarden la privacidad de los usuarios.

La privacidad por diseño se centra en incorporar principios de privacidad desde las primeras etapas del desarrollo, asegurando que los sistemas sean intrínsecamente respetuosos con la privacidad de los usuarios. Este enfoque proactivo implica anticipar y mitigar los riesgos de privacidad antes de que puedan afectar a los usuarios, integrando mecanismos de protección en el propio diseño del sistema.

Por otro lado, la seguridad por diseño se enfoca en implementar medidas de seguridad robustas desde el inicio del desarrollo de software o hardware. Este enfoque preventivo busca evitar fallos de seguridad y eliminar la necesidad de correcciones reactivas, garantizando que la infraestructura y los controles de seguridad sean sólidos desde el principio.

También se revisarán los principios de seguridad establecidos por OWASP y las directrices de la norma ISO/IEC 27002:2013, proporcionando un marco comprehensivo para la adquisición, desarrollo y mantenimiento de sistemas de información seguros. Además, se discuten las mejores prácticas dentro del Ciclo de Vida del Desarrollo de Software Seguro (S-SDLC) y se presenta el sistema de evaluación de vulnerabilidades de software CVSS v3.0.

Al seguir estas prácticas y principios, los desarrolladores y organizaciones pueden construir software que no solo cumpla con los estándares de seguridad y privacidad, sino que también genere confianza entre los usuarios y proteja contra amenazas en constante evolución.

2. Privacidad por diseño

La privacidad por diseño es un enfoque que integra la privacidad y la protección de datos personales desde las primeras etapas del desarrollo de un sistema, proceso o servicio. Este enfoque proactivo busca anticipar y mitigar los riesgos de privacidad antes de que se materialicen, garantizando que los principios de privacidad estén profundamente integrados en el propio diseño del sistema.

• Análisis del Impacto en la Privacidad: Antes de iniciar el desarrollo de un nuevo sistema, proceso o servicio, es fundamental analizar el impacto en la privacidad. Este análisis implica evaluar cómo el funcionamiento del sistema afectará la privacidad de los usuarios y determinar los riesgos potenciales que podrían surgir. Identificar estos riesgos permite explorar soluciones efectivas y desarrollar controles adecuados.

• Evaluación de Riesgos: Una vez identificados los riesgos, se procede a evaluarlos detalladamente. Esta evaluación incluye considerar las posibles consecuencias de cada riesgo y la probabilidad de que ocurra. Con esta información, se pueden priorizar los riesgos y diseñar estrategias específicas para mitigarlos.

• Desarrollo de Controles y Soluciones: Con los riesgos evaluados, el siguiente paso es desarrollar controles y soluciones que se incorporen directamente en el diseño del sistema. Estos controles deben ser efectivos para prevenir los riesgos identificados y deben estar alineados con las normativas de privacidad y protección de datos aplicables.

La privacidad por diseño se basa en una serie de principios clave que guían el desarrollo de sistemas seguros y respetuosos con la privacidad:

1. Proactivo, no reactivo; preventivo, no correctivo: Este principio enfatiza la importancia de anticipar y prevenir los problemas de privacidad antes de que ocurran, en lugar de reaccionar a ellos después de que se han materializado.

2. Privacidad como la configuración predeterminada: Los sistemas deben estar configurados para proteger la privacidad por defecto, sin requerir la intervención del usuario.

3. Privacidad incrustada en el diseño: La privacidad no debe ser un complemento, sino una parte integral del diseño del sistema.

4. Funcionalidad total - Todas las partes ganan: El diseño del sistema debe buscar una solución en la que todas las partes involucradas se beneficien, sin sacrificar la funcionalidad o la privacidad.

5. Seguridad extremo a extremo: La protección de la privacidad debe abarcar todo el ciclo de vida de los datos, desde la recopilación hasta la eliminación.

6. Visibilidad y transparencia: Las prácticas de privacidad deben ser transparentes y verificables, fomentando la confianza de los usuarios.

7. Respeto por la privacidad de los usuarios: Los sistemas deben estar centrados en el usuario, respetando y protegiendo sus derechos y expectativas de privacidad.

Incorporar mecanismos de prevención en el diseño del sistema es crucial. Estos mecanismos pueden incluir la anonimización y seudonimización de datos, políticas estrictas de acceso y control, y herramientas de monitoreo y auditoría para garantizar que las prácticas de privacidad se mantengan efectivas a lo largo del tiempo. En particular cuando la legislación exige la publicación de datos abiertos y la recopilación de datos personales.

2.a. Normativas Relacionadas con la Privacidad

Es esencial que el diseño del sistema cumpla con las normativas y regulaciones relacionadas con la privacidad y la protección de datos, como la ley 1581 de 2012 en Colombia, el Reglamento General de Protección de Datos (GDPR) de la Unión Europea, la Ley de Privacidad del Consumidor de California (CCPA) o aquellas que apliquen a la región del interesado.

Cumplir con estas normativas no solo es una obligación legal, sino también una práctica que refuerza la confianza del usuario y mejora la reputación de la organización.

Al adoptar la privacidad por diseño, las organizaciones pueden garantizar que sus sistemas y servicios no solo cumplan con los estándares de privacidad, sino que también protejan eficazmente los datos personales de los usuarios, creando un entorno más seguro y confiable.

Desafíos regulatorios

Hay que tener claro que la legislación, en muchos casos puede llegar a ser contradictoria o plantear desafíos tecnológicos que, en la práctica, no pueden ser solucionados.

Un caso particular sucede con la ley 1581 de 2012 exige que un usuario puede exigir que se dén de baja sus datos personales. Supongamos el caso en el cual una organización saca un backup de un sistema de información y al poco tiempo un ciudadano exige la eliminación de sus datos. ¿Es necesario que la organización tenga que revisar sus archivos de backup en busca de ésos datos personales y eliminarlos? ¿Cuán costosa sería ésa operación? ¿qué riesgos estrían asociados al daño de los backups por estarlos manipulando?.

Continuando con el caso hipotético, supongamos, que sucede un incidente y que la empresa recupera un backup previo a la eliminación de los datos personales del ciudadano. Dado el incidente, la entidad no tiene claridad sobre la solicitud de eliminación de los datos del ciudadano y continúa su operación. ¿hay una contravención a la ley? ¿cuales consecuencias tendría la entidad? ¿puede aplicarse el principio de buena fé?

Igualmente la Ley 1712 de 2014 “Transparencia en el acceso a la información pública” plantea una serie de exigencias de publicación de datos de las entidades públicas y, con fines estadísticos, el ministerio de salud exige a clínicas y hospitales publicar los datos de los pacientes. ¿hasta qué punto entran en contradicción las leyes?

En Estados Unidos se analizó un censo en 1990 en el cual se encontró que 216 millones de censados tenían características únicas al combinar la información de su código postal, fecha de nacimiento y sexo que permitirían a un ciberdelincuente inferir la identidad del ciudadano. Teniendo en cuenta que la totalidad del censo fue de 248 millones de habitantes, se está exponiendo la identidad del 87% de los censados.

El estudio cruzó las bases de datos públicas de los partidos políticos, que por ley debían incluír: nombre, dirección, ZIP, fecha de nacimiento, sexo, partido político, con fines de transparencia durante las elecciones y los datos publicados por los hospitales que incluían: ZIP, fecha de nacimiento, sexo, etnicidad, fecha de visita, historia clínica. El cruce de éstas bases de datos permitió identificar unívocamente la identidad de los ciudadanos y asociarla con su historia clínica.

3. Seguridad por diseño

La seguridad por diseño es un enfoque fundamental para el desarrollo de software y hardware, que integra principios y prácticas de seguridad desde el inicio del proyecto. Este enfoque busca prevenir vulnerabilidades y asegurar que los sistemas sean robustos y resistentes a las amenazas desde su concepción, minimizando la necesidad de correcciones posteriores y garantizando un entorno seguro durante todo el ciclo de vida del sistema.

3.a. Enfoque Proactivo para Proyectos Tecnológicos

Adoptar la seguridad por diseño implica considerar la seguridad como un componente integral de cada etapa del desarrollo de un proyecto tecnológico. Desde la planificación inicial hasta el despliegue y mantenimiento, la seguridad debe ser una prioridad. Este enfoque ayuda a prevenir fallos de seguridad tecnológicos y evita la necesidad de corregir problemas una vez que el sistema está en funcionamiento.

3.b. Automatización de Controles de Seguridad

Automatizar los controles de seguridad de los datos y el diseño de la infraestructura es crucial para garantizar la consistencia y efectividad de las medidas de protección. La automatización reduce la posibilidad de errores humanos y permite una respuesta rápida y eficiente a posibles amenazas. Además, facilita la implementación de políticas de seguridad coherentes y actualizadas a lo largo del tiempo.

3.c. OWASP

El Open Web Application Security Project, conocido comúnmente como OWASP, es una organización sin fines de lucro dedicada a mejorar la seguridad del software. Su principal objetivo es proporcionar recursos, herramientas y conocimientos para ayudar a las organizaciones a desarrollar, adquirir y mantener software seguro.

Las actividades de OWASP incluyen:

1. Documentación y Guías: OWASP publica una amplia gama de documentos, guías y herramientas que cubren aspectos clave de la seguridad de las aplicaciones web y móviles. Estos recursos son utilizados por desarrolladores, profesionales de seguridad y gestores de proyectos para mejorar la seguridad de sus aplicaciones.

2. Proyectos de Software Libre: OWASP promueve y apoya el desarrollo de herramientas de software libre y de código abierto diseñadas para mejorar la seguridad de las aplicaciones. Estos proyectos abordan áreas como la seguridad de código, pruebas de penetración, gestión de vulnerabilidades, entre otros.

3. Conferencias y Eventos: OWASP organiza conferencias y eventos en todo el mundo donde profesionales de la seguridad informática pueden compartir conocimientos, mejores prácticas y experiencias relacionadas con la seguridad de las aplicaciones.

4. Educación y Capacitación: La organización fomenta la educación en seguridad informática mediante la publicación de materiales educativos, la organización de cursos de formación y la promoción de la certificación en seguridad de aplicaciones.

Principios de Seguridad según OWASP

En particular OWASP proporciona una serie de principios clave que guían la seguridad por diseño:

1. Minimizar la superficie de ataque: Reducir la cantidad de código, funcionalidades y puntos de entrada expuestos a posibles ataques.

2. Establecer valores seguros por defecto: Configurar el sistema de manera que, por defecto, sea seguro, sin requerir configuraciones adicionales para asegurar su protección.

3. Privilegio mínimo: Otorgar a los usuarios y procesos solo los permisos necesarios para realizar sus funciones, minimizando el riesgo de abuso.

4. Defensa en profundidad: Implementar múltiples capas de seguridad para proteger el sistema, de modo que si una capa falla, las otras sigan proporcionando protección.

5. Fallar de forma segura: Diseñar el sistema para que, en caso de fallos, estos no comprometan la seguridad del sistema.

6. No confiar en los servicios: Asumir que todos los servicios externos son inseguros y validar y sanitizar todos los datos recibidos.

7. Separación de funciones: Asegurar que las funciones críticas del sistema estén separadas para evitar conflictos de interés y limitar el alcance de posibles fallos.

8. Evitar la seguridad por oscuridad: No depender de la confidencialidad de la implementación para la seguridad; en su lugar, utilizar controles de seguridad probados y documentados.

9. Mantener simple la seguridad: Diseñar sistemas sencillos y fáciles de entender, lo que facilita su auditoría y reducción de errores.

10. Arreglar los problemas de seguridad de forma correcta: Resolver las vulnerabilidades de manera integral, sin aplicar soluciones temporales que podrían fallar en el futuro.

11. Implementación de Seguridad desde el Inicio del Proyecto: Incorporar la seguridad desde el inicio del proyecto tecnológico es esencial. Esto incluye la selección de arquitecturas y tecnologías que soporten principios de seguridad robustos y la implementación de prácticas de desarrollo seguro, como la revisión de código y pruebas de penetración, desde las primeras fases del proyecto.

4. Confianza por Diseño

Además de la seguridad por diseño, algunos marcos de referencia se enfocan en la "confianza por diseño". Este enfoque busca construir sistemas que no solo sean seguros, sino también confiables y transparentes para los usuarios, asegurando que las medidas de seguridad sean visibles y comprensibles.

Confianza por Diseño es un enfoque que se centra en construir sistemas y servicios que sean intrínsecamente confiables para los usuarios y las partes interesadas. La confianza es un elemento esencial en cualquier interacción digital y se gana a través de la transparencia, la seguridad, la privacidad y la calidad del servicio.

Para lograr la Confianza por Diseño, las organizaciones deben adoptar prácticas que aseguren la integridad y disponibilidad de los sistemas, la precisión y fiabilidad de los datos, y la honestidad en la comunicación. Esto incluye la implementación de políticas claras de uso de datos, la garantía de que las promesas de seguridad y privacidad se cumplan y la provisión de mecanismos para que los usuarios reporten problemas y reciban respuestas rápidas y efectivas.

Además, la Confianza por Diseño también implica la responsabilidad y el compromiso ético. Las organizaciones deben estar dispuestas a asumir la responsabilidad en caso de fallos y a realizar las acciones correctivas necesarias. También deben comprometerse a operar de manera ética, respetando los derechos de los usuarios y priorizando su bienestar.

La confianza es difícil de construir pero fácil de destruir. Por lo tanto, es esencial que las organizaciones inviertan en construir confianza desde el inicio, asegurando que todos los aspectos de su operación —desde la tecnología hasta la atención al cliente— estén alineados con los principios de honestidad y transparencia.

4.a. Un Triángulo de Protección Integral

La integración de la Seguridad por Diseño, Privacidad por Diseño y Confianza por Diseño no es solo una práctica recomendada, sino una necesidad en el entorno digital actual. Estos tres enfoques crean un triángulo de protección integral que fortalece la seguridad de los sistemas, protege la privacidad de los usuarios y construye la confianza necesaria para las relaciones digitales sostenibles.

Las organizaciones que adopten estos principios estarán mejor preparadas para enfrentar los desafíos del futuro, no solo cumpliendo con los estándares normativos, sino también destacándose como líderes en responsabilidad digital y ética tecnológica.

5. Normas ISO orientadas a desarrollo de software

Para ayudar a las organizaciones a garantizar que sus productos cumplan con las expectativas de los usuarios y protejan la información que manejan, existen una serie de normas internacionales emitidas por la ISO (International Organization for Standarization) que establecen estándares rigurosos en cada fase del ciclo de vida del software.

ISO son las siglas de la "International Organization for Standardization" (Organización Internacional de Normalización). Es una organización no gubernamental internacional que desarrolla y publica estándares internacionales en una amplia variedad de campos, incluyendo tecnología, seguridad, salud, medio ambiente, y más.

El objetivo de ISO es proporcionar especificaciones y normas que aseguren la calidad, seguridad, eficiencia y compatibilidad de productos, servicios y sistemas a nivel global. Los estándares ISO son reconocidos y adoptados por organizaciones de todo el mundo para garantizar que sus productos y procesos cumplan con criterios internacionales.

Se exploran cuatro normas ISO clave orientadas al desarrollo de software: ISO 25000, ISO 9126, ISO 9001 e ISO 15504.

Las normas ISO descritas son herramientas fundamentales para cualquier organización que busque desarrollar software de alta calidad. Cada una de ellas ofrece un enfoque estructurado para evaluar, gestionar y mejorar la calidad del software, asegurando que los productos no solo cumplan con los requisitos técnicos, sino que también generen confianza y satisfacción en los usuarios. En un mundo donde la seguridad y la calidad son cruciales, la adopción de estas normas es un paso esencial para cualquier organización comprometida con la excelencia en el desarrollo de software.

ISO 25000: Requisitos y Evaluación de Calidad de Productos de Software (SQuaRE)

La norma ISO/IEC 25000, también conocida como SQuaRE (System and Software Quality Requirements and Evaluation), establece un marco integral para la gestión de la calidad en productos de software. Su objetivo es asegurar que los sistemas de software sean seguros, funcionales y se desarrollen de acuerdo con los más altos estándares de calidad.

ISO 25000 se divide en cinco áreas fundamentales, cada una representada por una subnorma específica:

1. ISO 2500n: Gestión de la calidad del software.

2. ISO 2501n: Modelos de calidad del software.

3. ISO 2502n: Medición de la calidad del software.

4. ISO 2503n: Requisitos de calidad del software.

5. ISO 2504n: Evaluación de la calidad del software.

El cumplimiento de estas cinco subnormas garantiza que los productos de software desarrollados no solo cumplan con las expectativas de calidad, sino que también ofrezcan confianza a los usuarios y a las organizaciones que los implementan.

ISO 9126: Evaluación de Productos de Software

Publicada en 1992, la norma ISO 9126 se centra en la evaluación de la calidad de los productos de software mediante el análisis de seis características clave: funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad.

1. Funcionalidad: Evalúa si el software cumple con los requisitos para las cuales fue diseñado.

2. Confiabilidad: Mide la capacidad del software para mantener su nivel de rendimiento bajo condiciones específicas.

3. Usabilidad: Analiza qué tan fácil es para los usuarios interactuar con el software.

4. Eficiencia: Se enfoca en el rendimiento y el uso óptimo de los recursos.

5. Mantenibilidad: Evalúa la facilidad con la que el software puede ser modificado y verificado.

6. Portabilidad: Analiza la capacidad del software para ser transferido de un entorno a otro.

La norma ISO 9126 es esencial para determinar si un desarrollo de software cumple con las necesidades de sus usuarios y es capaz de operar eficientemente en diferentes escenarios.

ISO 9001: Gestión de la Calidad aplicada al desarrollo de Software

La norma ISO 9001 es ampliamente conocida por su enfoque en la satisfacción del cliente y la mejora continua de los procesos dentro de una organización. En el contexto del desarrollo de software, ISO 9001 establece las bases para implementar un sistema de gestión de calidad que asegure que los productos de software no solo cumplan con los requisitos técnicos, sino que también generen confianza y credibilidad entre los usuarios.

Esta norma es una de las más adoptadas globalmente, con cientos de miles de certificaciones, lo que refuerza su importancia y eficacia en la mejora de la calidad del software.

ISO 15504: Evaluación de la Capacidad de Mejora del Proceso (SPICE)

También conocida como SPICE, la norma ISO 15504 se enfoca en la evaluación y mejora de los procesos de desarrollo de software. Esta norma establece un marco para medir la madurez y la capacidad de los procesos en diversas áreas, incluyendo procesos primarios como la ingeniería y la operación, procesos de soporte y procesos organizacionales como la gestión de recursos humanos e infraestructura.

El cumplimiento de los requisitos establecidos en ISO 15504 asegura que una organización no solo está desarrollando software de alta calidad, sino que también está continuamente mejorando sus procesos para mantenerse a la vanguardia de la industria.

6. ISO/IEC 27002:2013

La norma ISO/IEC 27002:2013 proporciona un marco integral de buenas prácticas para la gestión de la seguridad de la información, abarcando 14 dominios, 35 objetivos de control y 114 controles específicos. La versión 2022 de la norma ha unificado y resumido muchos controles, en particular los relacionados con la seguridad durante el desarrollo y adquisición de software, de tal forma que en éste documento se centra la atención en la versión 2013, que es más detallada en estos aspectos, particularmente el capítulo 14 sobre adquisición, desarrollo y mantenimiento de sistemas de información.

14. Adquisición, Desarrollo y Mantenimiento de los Sistemas de Información

14.1 Requisitos de Seguridad de los Sistemas de Información

• 14.1.1 Análisis y Especificación de los Requisitos de Seguridad: Identificar y documentar los requisitos de seguridad necesarios para el sistema desde las primeras etapas de desarrollo.

• 14.1.2 Seguridad de las Comunicaciones en Servicios Accesibles por Redes Públicas: Asegurar que las comunicaciones que pasan por redes públicas estén adecuadamente protegidas contra intercepciones y alteraciones.

• 14.1.3 Protección de las Transacciones por Redes Telemáticas: Implementar medidas de protección para garantizar la seguridad y la integridad de las transacciones que se realizan a través de redes telemáticas.

14.2 Seguridad en los Procesos de Desarrollo y Soporte

• 14.2.1 Política de Desarrollo Seguro de Software: Establecer políticas y procedimientos para asegurar que el desarrollo de software sigue prácticas seguras y que el código está libre de vulnerabilidades conocidas.

• 14.2.2 Procedimientos de Control de Cambios en los Sistemas: Implementar procedimientos estrictos para gestionar y controlar los cambios en los sistemas, asegurando que se realicen de manera segura y que se revisen adecuadamente.

• 14.2.3 Revisión Técnica de las Aplicaciones tras Efectuar Cambios en el Sistema Operativo: Realizar revisiones técnicas exhaustivas de las aplicaciones después de cualquier cambio en el sistema operativo para asegurar que la funcionalidad y la seguridad no se vean comprometidas.

• 14.2.4 Restricciones a los Cambios en los Paquetes de Software: Imponer restricciones y controles sobre los cambios realizados en los paquetes de software para prevenir alteraciones no autorizadas o inseguras.

• 14.2.5 Uso de Principios de Ingeniería en Protección de Sistemas: Adoptar principios de ingeniería sólidos para la protección de sistemas, tales como:

• • Modelo de permisos mínimos: Otorgar solo los permisos necesarios para las funciones específicas.

  • Limpiar el código que se pone en producción: Asegurarse de que el código en producción esté libre de vulnerabilidades y errores.

  • Nunca confiar en los datos que ingresan a la aplicación: Validar y sanitizar todos los datos de entrada.

  • Hacer un seguimiento de las tecnologías utilizadas para el desarrollo: Mantener un registro y evaluar continuamente las tecnologías empleadas.

  • Todos los accesos que se hagan a los sistemas deben ser validados: Implementar mecanismos de autenticación y autorización robustos.

  • Utilizar protocolos para cifrar las comunicaciones: Asegurar que las comunicaciones y la información confidencial estén cifradas.

  • Lo nuevo debe agregarse de acuerdo a los requerimientos de diseño: Garantizar que cualquier adición o cambio cumpla con los requisitos de diseño establecidos.

  • La información almacenada en dispositivos móviles debería ser la mínima: Limitar la cantidad de información confidencial “almacenada en” o “transmitida a” dispositivos móviles.

  • Cualquier cambio que se haga debería quedar documentado: Mantener una documentación detallada de todos los cambios realizados.

  • Poner más cuidado en los puntos más vulnerables: Enfocar esfuerzos adicionales en proteger los puntos más vulnerables del sistema.

• 14.2.6 Seguridad en Entornos de Desarrollo: Garantizar que los entornos de desarrollo estén adecuadamente protegidos contra accesos no autorizados y otras amenazas.

• 14.2.7 Externalización del Desarrollo de Software: Asegurar que las actividades de desarrollo de software externalizadas se realicen de acuerdo con las políticas de seguridad y bajo estrictos controles.

• 14.2.8 Pruebas de Funcionalidad durante el Desarrollo de los Sistemas: Realizar pruebas exhaustivas de funcionalidad para asegurar que los sistemas operen según lo previsto y que cumplan con los requisitos de seguridad.

• 14.2.9 Pruebas de Aceptación: Llevar a cabo pruebas de aceptación para validar que los sistemas cumplen con los requisitos funcionales y de seguridad antes de su implementación final.

14.3 Datos de Prueba

• 14.3.1 Protección de los Datos Utilizados en Pruebas: Asegurar que los datos utilizados durante las pruebas estén protegidos adecuadamente para evitar comprometer la seguridad y la privacidad.

7. SDLC: Ciclo de Vida del Desarrollo de Software

Tradicionalmente el Ciclo de Vida del Desarrollo de Software (SDLC) es un proceso estructurado utilizado para desarrollar sistemas de software con un alto nivel de calidad y eficiencia. El SDLC abarca desde la planificación inicial hasta la implementación y el mantenimiento, asegurando que los objetivos de seguridad y funcionalidad se cumplan en cada etapa.

Los objetivos del SDLC tradicional son:

• Inclusión de controles de seguridad y validación de datos: Integrar medidas de seguridad en cada fase del desarrollo para proteger la integridad y confidencialidad de los datos.

• Definir y documentar las normas y procedimientos que se aplicarán: Establecer estándares y procedimientos claros para guiar el desarrollo y asegurar la calidad del software.

• Aplicativos e infraestructura de base: Garantizar que tanto las aplicaciones como la infraestructura subyacente estén diseñadas para ser seguras y eficientes.

• Definir los métodos de protección de la información crítica o sensible: Implementar estrategias de protección de datos para resguardar la información sensible contra accesos no autorizados.

• Diseño e implantación de los sistemas de información que sustentan los procesos de negocio: Asegurar que los sistemas de información sean seguros, robustos y capaces de soportar los procesos de negocio críticos.

7.a. Proceso S-SDLC: Ciclo de Vida del Desarrollo de Software Seguro

El S-SDLC añade un enfoque de seguridad al SDLC tradicional, integrando controles de seguridad en cada fase del ciclo de vida del desarrollo de software.

Fases y Roles que establece el S-SDLC:

• Security Requirements (Requisitos de Seguridad):

  • Establecer requerimientos y controles de seguridad cuantificables: Definir de manera precisa y medible los requisitos de seguridad que el software debe cumplir.

  • Control de autenticación: Implementar mecanismos de autenticación robustos.

  • Creación de usuarios con contraseña robusta: Asegurar que las contraseñas sean complejas y seguras.

  • Control de roles y privilegios: Limitar los permisos de los usuarios al mínimo necesario para realizar sus tareas.

  • Requerimientos orientados al riesgo: Identificar y mitigar los riesgos específicos asociados con el software.

  • Aprobación de privilegios: Autorizar el acceso de los usuarios únicamente a lo que es imprescindible.

• Threat Modeling (Modelado de Amenazas):

  • Asegurar desde el análisis y diseño: Incorporar la seguridad desde las primeras fases del proyecto.

  • Diseño seguro de mensajes de error: Asegurar que los mensajes de error no revelen información sensible.

  • Diseño seguro de autenticación, autoría y logging: Implementar métodos seguros para autenticar usuarios, registrar eventos y asegurar la autoría.

  • Análisis de riesgo: Evaluar y mitigar los riesgos asociados con el software.

• Implementación y Codificación:

  • Validar siempre los datos de entrada antes de procesarlos: Asegurar que los datos de entrada sean correctos y seguros.

  • Listas blancas: Utilizar listas blancas para validar datos.

  • Controlar el tamaño y tipos de datos de entrada: Restringir el tamaño y tipo de los datos que se pueden ingresar.

  • Validación de dominio: Comprobar que los datos de entrada cumplan con las reglas de negocio.

  • Eliminar caracteres especiales: Prevenir inyecciones de código eliminando caracteres especiales.

  • Transformar los datos de entrada en un código establecido: Normalizar los datos antes de procesarlos.

  • Archivos de configuración y parametrización: Mantener configuraciones y parámetros seguros.

  • Reemplazar sentencias SQL dinámicas por stored procedures: Utilizar procedimientos almacenados en lugar de SQL dinámico para prevenir inyecciones SQL.

• Implantación y Pruebas:

  • Pruebas de código estático: Utilizar herramientas como BurpSuite, Veracode, Checkmarx SAST para identificar vulnerabilidades en el código.

  • Pruebas de código dinámico: Evaluar la seguridad durante la ejecución del software mediante pruebas de estrés, caída y carga.

  • Pruebas de penetración: Realizar pruebas de penetración para identificar y mitigar posibles vulnerabilidades.

Modelos S-SDLC

Actualmente varias organizaciones han descrito sus metodologías de desarrollo que cumplen con el S-SDLC. Enumeramos a continuación las más importantes:

• Microsoft Trustworthy Computing SDL: Enfocado en asegurar que el software cumple con estándares de seguridad desde la concepción hasta la implementación y el mantenimiento.

• McGraw's: Incluye revisión de código, análisis de riesgo, pruebas de intrusión y requisitos de seguridad específicos para desarrolladores.

• CLASP - Comprehensive Lightweight Application Security Process (OWASP): Ofrece una serie de vistas (conceptual, basada en roles, implementación, vulnerabilidad) para guiar el desarrollo seguro de aplicaciones.

• Writing Secure Code: Enfocado en técnicas y prácticas para escribir código seguro, evitando vulnerabilidades comunes.

• TSP-Secure: Incorpora prácticas de seguridad en el Proceso de Software del Equipo (Team Software Process), asegurando que los equipos de desarrollo sigan prácticas de seguridad durante todo el ciclo de vida del desarrollo.

8. Evaluación de Vulnerabilidades de Software con CVSS

El Common Vulnerability Scoring System (CVSS) es un estándar ampliamente utilizado para evaluar y medir la severidad de las vulnerabilidades de software. La versión 3.0 del CVSS introduce mejoras significativas sobre las versiones anteriores, proporcionando un enfoque más preciso y detallado para la evaluación de vulnerabilidades.

El objetivo principal del CVSS es ofrecer una metodología objetiva para medir la severidad de las vulnerabilidades de software. Esto se logra mediante la evaluación de diversas métricas que reflejan tanto la facilidad de explotación de una vulnerabilidad como su impacto potencial.

8.a. Cambios del CVSS 2.0 al CVSS 3.0

Al ilustrar las diferencias que hay entre la penúltima versión y la última se puede vislumbrar la problemática asociada a la medición de las vulnerabilidades y cómo avanza el debate para poder obtener resultados cada vez más objetivos.

La versión 3.0 del CVSS introduce varias mejoras significativas con respecto a la versión anterior (v2.0), las cuales están diseñadas para proporcionar una evaluación más precisa y detallada de las vulnerabilidades. A continuación, se detallan los cambios clave:

• Impacto por Componente: el modelo ahora tiene la capacidad de evaluar el impacto específico de la vulnerabilidad en componentes individuales del sistema. Esto permite a los evaluadores y analistas de seguridad comprender mejor cómo una vulnerabilidad puede afectar diferentes partes o funcionalidades.

• Diferenciación de Ataques Locales y Físicos: se introduce una distinción clara entre los ataques que requieren acceso local y aquellos que requieren acceso físico al sistema afectado. Esta diferenciación es crucial, ya que los ataques que requieren acceso local pueden ser menos probables o más difíciles de ejecutar que los ataques que requieren acceso físico directo al dispositivo o sistema.

• Separación de Complejidad del Ataque e Interacción del Usuario: separa la complejidad del ataque de la necesidad de interacción del usuario para explotar la vulnerabilidad. Esto significa que se evalúa la dificultad relativa de llevar a cabo el ataque, así como la cantidad de interacción necesaria por parte del usuario final o del atacante para aprovechar la vulnerabilidad.

• Escala Cualitativa de Cinco Pasos: En lugar de la escala numérica de diez pasos utilizada en el CVSS v2.0, la versión 3.0 introduce una escala más detallada y cualitativa de cinco pasos para evaluar la severidad de las vulnerabilidades. Esto permite una clasificación más clara y comprensible de la gravedad de las vulnerabilidades, facilitando decisiones informadas sobre las prioridades de mitigación y respuesta.

8.b. Tipos de Métricas y Puntajes

El CVSS se compone de tres tipos principales de métricas: base, temporales y de ambiente.

Métricas Base

Las métricas base son independientes del tiempo y el lugar, y se dividen en dos categorías principales:

• Exploitability (Explotabilidad): Evalúa la dificultad para explotar la vulnerabilidad. Incluye factores como el vector de ataque, la complejidad del ataque, los privilegios requeridos y la interacción del usuario.

  • Attack Vector: Define el ámbito en el que se puede explotar la vulnerabilidad (e.g., red, local, físico).

  • Attack Complexity: Evalúa la dificultad de realizar el ataque (e.g., baja, alta).

  • Privileges Required: Determina el nivel de privilegios necesarios para explotar la vulnerabilidad (e.g., ninguno, usuario, administrador).

  • User Interaction: Indica si se requiere la interacción del usuario para explotar la vulnerabilidad (e.g., no, sí).

• Impact (Impacto): Mide las consecuencias directas de la explotación. Se enfoca en la confidencialidad, la integridad y la disponibilidad del sistema afectado.

• • Scope (Alcance): Indica si la explotación de la vulnerabilidad afecta otros componentes más allá del componente vulnerable original.

  • Confidentiality, Integrity, Availability: Evalúan el impacto en la confidencialidad, integridad y disponibilidad del sistema.

Métricas Temporales

Las métricas temporales reflejan el estado actual de la vulnerabilidad y su explotabilidad en un momento dado. Incluyen:

• Exploit Code Maturity: Evalúa la disponibilidad y sofisticación del código de explotación.

• Remediation Level: Mide el estado de las soluciones disponibles para mitigar la vulnerabilidad.

• Report Confidence: Indica la confianza en la existencia y detalles de la vulnerabilidad reportada.

Métricas de Ambiente

Las métricas de ambiente consideran las características específicas del entorno en el que se encuentra el sistema afectado. Evalúan el impacto de la vulnerabilidad en función de los requisitos de confidencialidad, integridad y disponibilidad del entorno.

8.c. Ejemplo de Vector CVSS

Un vector CVSS típico puede describirse de la siguiente manera:

• Attack Vector: Network

• Attack Complexity: Low

• Privileges Required: High

• User Interaction: None

• Scope: Unchanged

• Confidentiality Impact: Low

• Integrity Impact: Low

• Availability Impact: None

Representado como: CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N.

8.d. Uso en la Práctica

La evaluación de vulnerabilidades de software mediante el CVSS se ha vuelto esencial para las organizaciones que buscan priorizar sus esfuerzos de mitigación de riesgos. En la práctica, el uso de calculadoras en línea y la comprensión de las ecuaciones subyacentes permiten una evaluación precisa y objetiva. Este capítulo aborda cómo estas herramientas se utilizan y la importancia de las ecuaciones en el proceso de cálculo del puntaje final de vulnerabilidad.

Calculadoras en Línea

Las calculadoras en línea de CVSS son herramientas accesibles que simplifican el proceso de evaluación de vulnerabilidades. Estas calculadoras proporcionan una interfaz para ingresar las métricas de CVSS y automáticamente calcular el puntaje final. A continuación, se describen sus usos y beneficios:

1. Facilidad de Uso: Las calculadoras en línea están diseñadas para ser intuitivas, permitiendo a los analistas ingresar datos de manera sencilla sin necesidad de entender la complejidad de las ecuaciones subyacentes.

2. Consistencia y Precisión: Estas herramientas garantizan que las puntuaciones se calculen de manera consistente y precisa, eliminando el error humano que podría ocurrir al hacer los cálculos manualmente.

3. Comparación de Vulnerabilidades: Permiten la comparación rápida de múltiples vulnerabilidades, ayudando a priorizar las acciones de mitigación en función de las puntuaciones obtenidas.

4. Actualización Continua: Las calculadoras en línea suelen estar actualizadas con las últimas versiones de CVSS, garantizando que las evaluaciones se realicen con los criterios más recientes.

Ejemplos de calculadoras en línea incluyen:

• Calculadora de CVSS del NIST

• Calculadora de CVSS de FIRST

Ecuaciones de CVSS

Las ecuaciones utilizadas en CVSS son la base para calcular los puntajes de vulnerabilidad. Estas ecuaciones toman en cuenta diversas métricas y factores que determinan la severidad de una vulnerabilidad.

8.e. Importancia del Conocimiento del Ambiente

El conocimiento detallado del ambiente en el que opera un sistema es crucial para la evaluación precisa de vulnerabilidades utilizando el Common Vulnerability Scoring System (CVSS). Esta comprensión profunda permite a los analistas proporcionar una evaluación más contextualizada y relevante, que tiene en cuenta las características específicas del entorno y los posibles impactos de las vulnerabilidades identificadas.

Factores Clave del Conocimiento del Ambiente

1. Configuración Específica del Sistema: Cada sistema tiene una configuración única, que incluye su infraestructura de hardware y software, las aplicaciones en ejecución, los usuarios y sus roles, así como las políticas de seguridad implementadas. Conocer estas configuraciones permite evaluar cómo una vulnerabilidad puede afectar al sistema en particular.

2. Requisitos de Negocio y Procesos Operativos: Los sistemas operan en el contexto de los procesos de negocio y los requisitos operativos específicos. Entender estos procesos ayuda a identificar las áreas críticas que podrían ser más afectadas por una vulnerabilidad y a priorizar las medidas de mitigación.

3. Valor de los Activos: Algunos activos dentro de un sistema son más valiosos que otros. El conocimiento del valor de estos activos permite una evaluación más precisa del impacto potencial de una vulnerabilidad, ayudando a enfocar los esfuerzos de seguridad en proteger los activos más críticos.

4. Entorno de Red y Topología: La estructura de la red, incluyendo la segmentación de la red, los firewalls, los sistemas de detección de intrusiones y otros controles de seguridad de red, influye en cómo una vulnerabilidad puede ser explotada y propagarse. Un análisis detallado de la topología de la red es esencial para comprender las posibles rutas de ataque.

5. Cumplimiento Normativo y Requisitos Legales: Las organizaciones deben cumplir con diversas normativas y leyes que afectan cómo manejan la seguridad y la privacidad de los datos. Conocer estos requisitos permite evaluar cómo una vulnerabilidad podría impactar en el cumplimiento normativo y las posibles consecuencias legales.

6. Interdependencias de Sistemas: Los sistemas a menudo están interconectados e interdependientes. Una vulnerabilidad en un sistema puede tener un efecto dominó en otros sistemas conectados. Conocer estas interdependencias es crucial para evaluar el alcance y el impacto total de una vulnerabilidad.

Ejemplos de Evaluaciones Contextualizadas

1. Sistema Financiero: En un entorno bancario, la confidencialidad y la integridad de los datos son críticas. Una vulnerabilidad que afecte la confidencialidad de los datos financieros puede tener consecuencias severas. Conocer las transacciones específicas y los datos que maneja el sistema permite evaluar con precisión el impacto de una vulnerabilidad.

2. Sistema de Salud: En un entorno de salud, la disponibilidad del sistema es fundamental para la atención al paciente. Una vulnerabilidad que podría causar una interrupción del servicio debe ser evaluada con un enfoque en la disponibilidad y la integridad de los datos de los pacientes, considerando el impacto potencial en la atención médica.

3. Infraestructura Crítica: Los sistemas que gestionan infraestructuras críticas, como la energía o el agua, requieren un enfoque especial en la resiliencia y la disponibilidad. Conocer las especificidades de estos sistemas y las posibles consecuencias de una interrupción es vital para evaluar correctamente las vulnerabilidades.

Ajustes de Puntuación de CVSS Basados en el Ambiente

Las métricas ambientales del CVSS permiten ajustar las puntuaciones basadas en el contexto específico del entorno evaluado. Estos ajustes pueden reflejar:

• Importancia del Componente Vulnerable: Evaluar cuán crítico es el componente dentro del entorno del cliente.

• Impacto Contextual: Determinar cómo una vulnerabilidad puede afectar las operaciones diarias y los objetivos de negocio de la organización.

• Requisitos de Seguridad Específicos: Considerar los requisitos de confidencialidad, integridad y disponibilidad específicos del entorno.

Estos ajustes son esenciales para proporcionar una evaluación precisa y significativa, permitiendo a las organizaciones priorizar las vulnerabilidades y las medidas de mitigación de manera efectiva.

8.f. Resultados absolutos o relativos

Dado que el resultado de una evaluación de vulnerabilidades depende ampliamente del contexto, es probable que una misma vulnerabilidad tenga dos resultados diferentes para el mismo software en dos sistemas de información implantados en dos organizaciones diferentes. Es más, dos evaluadores pueden llegar a resultados diferentes al realizar el cálculo de la misma vulnerabilidad.

9. Planificación de Pruebas de Software Seguro

La planificación de pruebas de software es esencial para garantizar la calidad y seguridad. La naturaleza del software, ya sea adquirido o desarrollado internamente, influye significativamente en el enfoque y la selección de pruebas necesarias. En este capítulo se explora cómo diseñar un plan de pruebas efectivo, diferenciando entre los diferentes modelos de adquisición de software.

El desarrollo de un plan de pruebas efectivo para software seguro implica una comprensión clara de las diferencias entre adquirir software externo y desarrollarlo internamente. Al seleccionar y aplicar los tipos de pruebas adecuados para cada modelo, las organizaciones pueden mitigar riesgos y garantizar que sus aplicaciones sean seguras, confiables y conformes con las normativas vigentes.

Tipos de Pruebas para la Adquisición de Software

Cuando se adquiere software de proveedores externos, es crucial realizar pruebas específicas para asegurar su seguridad y funcionalidad. Los tipos de pruebas relevantes incluyen:

1. Pruebas de Seguridad del Proveedor: Verificación de las políticas y prácticas de seguridad del proveedor, así como la revisión de auditorías de seguridad previas del software.

2. Pruebas de Integración: Aseguramiento de que el software se integre correctamente con los sistemas y datos existentes sin comprometer la seguridad ni la estabilidad.

3. Pruebas de Penetración: Evaluación de la resistencia del software a intentos deliberados de compromiso de seguridad, buscando vulnerabilidades conocidas y desconocidas.

4. Pruebas de Cumplimiento: Verificación de que el software cumple con los estándares y regulaciones de seguridad pertinentes para el contexto operativo del cliente.

Tipos de Pruebas para Desarrollo In-House

Cuando el software se desarrolla internamente, el equipo de desarrollo tiene control directo sobre el proceso y los estándares de seguridad. Los tipos de pruebas que deben considerarse incluyen:

1. Pruebas Unitarias: Evaluación de componentes individuales del software para asegurar su correcto funcionamiento y la ausencia de vulnerabilidades específicas.

2. Pruebas de Integración Continua: Automatización de pruebas para detectar problemas de integración y asegurar la cohesión del sistema en desarrollo.

3. Análisis de Código Estático: Revisión del código fuente en busca de vulnerabilidades potenciales y prácticas de seguridad deficientes.

4. Pruebas de Aceptación del Usuario: Validación con usuarios finales para asegurar que el software cumple con los requisitos funcionales y de seguridad esperados.

Tipos de Pruebas Comunes a Ambos Modelos

Algunos tipos de pruebas son esenciales independientemente de cómo se obtenga el software. Estos incluyen:

1. Pruebas de Seguridad Funcional: Evaluación de la capacidad del software para resistir ataques y mantener la confidencialidad, integridad y disponibilidad de los datos.

2. Pruebas de Rendimiento:

   • Pruebas de Carga: Verificación de cómo el sistema maneja las cargas máximas esperadas, asegurando que no haya degradación del rendimiento ni vulnerabilidades por saturación.

   • Pruebas de Estrés: Evaluación de cómo el sistema responde bajo condiciones extremas de carga o recursos limitados, identificando puntos críticos de fallo y degradación.

3. Pruebas de Regresión: Aseguramiento de que las actualizaciones y modificaciones no introduzcan nuevos problemas de seguridad ni afecten el funcionamiento previamente validado.

4. Pruebas de Resiliencia: Evaluación de cómo el software responde y se recupera de eventos inesperados, como fallos de seguridad o caídas del sistema.

Licencia

 
Buenas prácticas para desarrollo de software seguro está bajo una licencia de Creative Commons Reconocimiento-CompartirIgual 4.0 Internacional.