Visión general
Una nueva categoría para 2021 se centra en los riesgos relacionados con los defectos de diseño y arquitectura, con un llamado a un mayor uso del modelado de amenazas, patrones de diseño seguro y arquitecturas de referencia. Como comunidad, debemos ir más allá de “cambiar a la izquierda” en el espacio de codificación para precodificar actividades que son críticas para los principios de Secure by Design. Las Enumeraciones de debilidades comunes (CWE) notables incluyen CWE-209: Generación de mensaje de error que contiene información confidencial , CWE-256: Almacenamiento desprotegido de credenciales , CWE-501: Violación de límites de confianza y CWE-522: Credenciales insuficientemente protegidas .
Descripción
El diseño inseguro es una categoría amplia que representa diferentes debilidades, expresadas como “diseño de control faltante o ineficaz”. El diseño inseguro no es la fuente de todas las demás categorías de riesgo Top 10. Hay una diferencia entre el diseño inseguro y la implementación insegura. Diferenciamos entre fallas de diseño y defectos de implementación por una razón, tienen diferentes causas y soluciones. Un diseño seguro aún puede tener defectos de implementación que den lugar a vulnerabilidades que pueden ser explotadas. Un diseño inseguro no puede solucionarse con 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 perfiles de riesgo empresarial inherentes al software o sistema que se está desarrollando.
Gestión de requisitos y recursos
Recopile y negocie los requisitos comerciales para una aplicación con la empresa, incluidos los requisitos de protección relacionados con la confidencialidad, la integridad, la disponibilidad y la autenticidad de todos los activos de datos y la lógica comercial esperada. Tenga en cuenta qué tan expuesta estará su aplicación y si necesita segregación de inquilinos (además del control de acceso). Compilar los requisitos técnicos, incluidos los requisitos de seguridad funcionales y no funcionales. Planifique y negocie el presupuesto que cubra todo el diseño, la construcción, las pruebas y la operación, incluidas las actividades de seguridad.
Diseño Seguro
El diseño seguro es una cultura y una metodología que evalúa constantemente las amenazas y garantiza que el código esté diseñado y probado de manera sólida para evitar métodos de ataque conocidos. El modelado de amenazas debe integrarse en las sesiones de perfeccionamiento (o actividades similares); busque cambios en los flujos de datos y control de acceso u otros controles de seguridad. En el desarrollo de la historia de usuario, determine el flujo correcto y los estados de falla, asegúrese de que las partes responsables e impactadas los entiendan bien y los acepten. Analice los supuestos y las condiciones para los flujos esperados y de fallas, asegúrese de que sigan siendo precisos y deseables. Determinar cómo validar las suposiciones y hacer cumplir las condiciones necesarias para los comportamientos adecuados. Asegúrese de que los resultados estén documentados en la historia del usuario. Aprenda de los errores y ofrezca incentivos positivos para promover mejoras.
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 seguros, herramientas y modelado de amenazas. Póngase en contacto con sus especialistas en seguridad al comienzo de un proyecto de software durante todo el proyecto y el mantenimiento de su software. Considere aprovechar el para ayudar a estructurar sus esfuerzos de desarrollo de software seguro.
Como prevenir
-
Establezca y use un ciclo de vida de desarrollo seguro con profesionales de AppSec para ayudar a evaluar y diseñar controles relacionados con la seguridad y la privacidad.
-
Establezca y utilice una biblioteca de patrones de diseño seguros o componentes de caminos pavimentados listos para usar
-
Utilice el modelado de amenazas para la autenticación crítica, el control de acceso, la lógica empresarial y los flujos de claves
-
Integre el lenguaje y los controles de seguridad en las historias de los usuarios
-
Integre verificaciones de plausibilidad en cada nivel de su aplicación (desde el frontend hasta el backend)
-
Escriba pruebas unitarias y de integración para validar que todos los flujos críticos sean resistentes al modelo de amenazas. Compile casos de uso y casos de uso indebido para cada nivel de su aplicación.
-
Separe las capas de niveles en las capas del sistema y de la red según las necesidades de exposición y protección
-
Separe a los inquilinos de manera sólida por diseño en todos los niveles
-
Limite el consumo de recursos por usuario o servicio
Ejemplos de escenarios de ataque
Escenario n.º 1: un flujo de trabajo de recuperación de credenciales puede incluir “preguntas y respuestas”, lo cual está prohibido por NIST 800-63b, OWASP ASVS y OWASP Top 10. No se puede confiar en las preguntas y respuestas como prueba de identidad de más de una persona. pueden saber las respuestas, por eso están prohibidas. Dicho código debe eliminarse y reemplazarse con un diseño más seguro.
Escenario n.º 2: una cadena de cines permite descuentos por reserva de grupo y tiene un máximo de quince asistentes antes de solicitar un depósito. Los atacantes podrían amenazar con modelar este flujo y probar si pueden reservar seiscientas butacas y todos los cines a la vez en unas pocas solicitudes, lo que provocaría una pérdida masiva de ingresos.
Escenario n.º 3: el sitio web de comercio electrónico de una cadena minorista no tiene protección contra los bots de los revendedores que compran tarjetas de video de alta gama para revender sitios web de subastas. Esto genera una publicidad terrible para los fabricantes de tarjetas de video y los dueños de las cadenas minoristas, y genera mala sangre entre los entusiastas que no pueden obtener estas tarjetas a ningún precio. Las reglas cuidadosas de lógica de dominio y diseño anti-bot, como las compras realizadas a los pocos segundos de disponibilidad, pueden identificar compras no auténticas y rechazar tales transacciones.
Referencias
Lista de CWE mapeados
Más información: