Resumen
Una nueva categoría para 2021 se enfoca en los riesgos relacionados con fallas de diseño y arquitectura, con un llamado a un mayor uso de modelado de amenazas, patrones de diseño seguro y arquitecturas de referencia. Como comunidad, necesitamos ir más allá del "shift-left" en el ámbito de la codificación hacia actividades previas al código que son críticas para los principios de "Seguridad por Diseño". Algunas de las enumeraciones de debilidades comunes (CWEs) notables incluyen CWE-209: Generación de Mensajes de Error que Contienen Información Sensible, CWE-256: Almacenamiento No Protegido de Credenciales, CWE-501: Violación del Límite de Confianza, y CWE-522: Credenciales Insuficientemente Protegidas.
Descripción
El diseño inseguro es una categoría amplia que representa diversas debilidades, expresadas como "diseño de control ausente o ineficaz". El diseño inseguro no es la fuente de todas las demás categorías de riesgo del Top 10. Hay una diferencia entre el diseño inseguro y la implementación insegura. Diferenciamos entre fallos de diseño y defectos de implementación por una razón: tienen diferentes causas raíz y remedios. Un diseño seguro aún puede tener defectos de implementación que conduzcan a vulnerabilidades que pueden ser explotadas. Un diseño inseguro no puede ser corregido por una implementación perfecta ya que, por definición, los controles de seguridad necesarios nunca se crearon para defenderse de ataques específicos. Uno de los factores que contribuyen al diseño inseguro es la falta de un perfil de riesgo empresarial inherente al software o sistema que se está desarrollando, y por lo tanto, la falla en determinar qué nivel de diseño de seguridad se requiere.
Gestión de Requisitos y Recursos
Recoge y negocia los requisitos empresariales de una aplicación con la empresa, incluyendo los requisitos de protección relacionados con la confidencialidad, integridad, disponibilidad y autenticidad de todos los activos de datos y la lógica empresarial esperada. Ten en cuenta cuán expuesta estará tu aplicación y si necesitas segregación de inquilinos (además del control de acceso). Compila los requisitos técnicos, incluidos los requisitos de seguridad funcionales y no funcionales. Planifica y negocia el presupuesto cubriendo todo el diseño, construcción, pruebas y operación, incluidas las actividades de seguridad.
Diseño seguro
El diseño seguro es una cultura y metodología que evalúa constantemente las amenazas y asegura que el código esté diseñado y probado de manera robusta para prevenir métodos de ataque conocidos. El modelado de amenazas debe integrarse en las sesiones de refinamiento (o actividades similares); busca cambios en los flujos de datos y en el control de acceso u otros controles de seguridad. En el desarrollo de la historia de usuario, determina el flujo correcto y los estados de fallo, asegurando que sean bien entendidos y acordados por las partes responsables e impactadas. Analiza las suposiciones y condiciones para los flujos esperados y de fallos, asegurando que sigan siendo precisos y deseables. Determina cómo validar las suposiciones y hacer cumplir las condiciones necesarias para comportamientos adecuados. Asegura que los resultados se documenten en la historia de usuario. Aprende de los errores y ofrece incentivos positivos para promover mejoras. El diseño seguro no es un complemento ni una herramienta que se pueda agregar al software.
Ciclo de Vida de Desarrollo Seguro
El software seguro requiere un ciclo de vida de desarrollo seguro, alguna forma de patrón de diseño seguro, metodología de camino pavimentado, biblioteca de componentes asegurados, herramientas y modelado de amenazas. Involucra a tus especialistas en seguridad desde el inicio de un proyecto de software, a lo largo de todo el proyecto y durante el mantenimiento de tu software. Considera aprovechar el Modelo de Madurez de Aseguramiento de Software de OWASP (SAMM) para ayudar a estructurar tus esfuerzos de desarrollo de software seguro.
Cómo prevenir
- Establecer y utilizar un ciclo de vida de desarrollo seguro con profesionales de seguridad de aplicaciones (AppSec) para ayudar a evaluar y diseñar controles relacionados con la seguridad y la privacidad.
- Establecer y utilizar una biblioteca de patrones de diseño seguro o componentes listos para usar en un camino pavimentado.
- Utilizar el modelado de amenazas para la autenticación crítica, el control de acceso, la lógica de negocio y los flujos clave.
- Integrar el lenguaje y los controles de seguridad en las historias de usuario.
- Integrar comprobaciones de plausibilidad en cada nivel de tu aplicación (desde el frontend hasta el backend).
- Escribir pruebas unitarias e integradoras para validar que todos los flujos críticos son resistentes al modelo de amenazas. Compilar casos de uso y de abuso para cada nivel de tu aplicación.
- Segregar las capas de nivel en los sistemas y capas de red dependiendo de la exposición y necesidades de protección.
- Segregar inquilinos de manera robusta por diseño en todos los niveles.
- Limitar el consumo de recursos por usuario o servicio.
Escenarios de Ataques Ejemplares
Escenario #1: Un flujo de recuperación de credenciales podría incluir "preguntas y respuestas", lo cual está prohibido por NIST 800-63b, OWASP ASVS y OWASP Top 10. Las preguntas y respuestas no se pueden confiar como evidencia de identidad, ya que más de una persona puede conocer las respuestas, por lo que están prohibidas. Dicho código debería eliminarse y reemplazarse por un diseño más seguro.
Escenario #2: Una cadena de cines permite descuentos por reservas grupales y tiene un máximo de quince asistentes antes de requerir un depósito. Los atacantes podrían modelar amenazas en este flujo y probar si pueden reservar seiscientos asientos y todos los cines a la vez en unas pocas solicitudes, causando una gran pérdida de ingresos.
Escenario #3: El sitio web de comercio electrónico de una cadena de minoristas no tiene protección contra bots que son utilizados por revendedores para comprar tarjetas de video de alta gama y revenderlas en sitios de subastas. Esto crea una mala publicidad para los fabricantes de tarjetas de video y los propietarios de la cadena de minoristas, además de un malestar duradero con los entusiastas que no pueden obtener estas tarjetas a ningún precio. Un diseño cuidadoso contra bots y reglas de lógica de dominio, como compras realizadas dentro de unos segundos de disponibilidad, podrían identificar compras no auténticas y rechazar dichas transacciones.