Insecure Design

## 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 las otras 10 categorías. Existe una diferencia entre un diseño inseguro y una implementación insegura. Distinguimos entre fallas de diseño y defectos de implementación por un motivo, difieren en la causa raíz y remediaciones. Incluso un diseño seguro puede tener defectos de implementación que conduzcan a vulnerabilidades que pueden explotarse. Un diseño inseguro no se puede arreglar 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 y, por lo tanto, la falta de determinación del nivel de diseño de seguridad que se requiere. ### Gestión de requerimientos y recursos Recopile y negocie los requerimientos para la aplicación con el negocio, incluidos los requisitos de protección relacionados con la confidencialidad, integridad, disponibilidad y autenticidad de todos los activos de datos y la lógica de negocio esperada. Tenga en cuenta qué tan expuesta estará su aplicación y si necesita segregación de funcionalidades (además del control de acceso). Recopile los requerimientos técnicos, incluidos los funcionales de seguridad y los no funcionales. Planifique y negocie que el presupuesto cubra el diseño, construcción, prueba y operación, incluyendo las actividades de seguridad. ### Diseño seguro El diseño seguro es una cultura y metodología que evalúa constantemente las amenazas y garantiza que el código esté diseñado y probado de manera sólida para prevenir métodos de ataque conocidos. El modelado de amenazas debe estar integrado en sesiones de refinamiento (o actividades similares); buscar cambios en los flujos de datos y el control de acceso u otros controles de seguridad. Durante la creación de las historias de usuario, determine el flujo correcto y los estados de falla. Asegúrese de que sean bien entendidos y acordados por las partes responsables e impactadas. Analice las suposiciones y las condiciones para los flujos esperados y de falla, asegúrese de que aún sean precisos y deseables. Determine 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 las historias de usuario. Aprenda de los errores y ofrezca incentivos positivos para promover mejoras. El diseño seguro no es un complemento ni una herramienta que pueda agregar al software. ### Ciclo de Desarrollo Seguro (S-SDLC) El software seguro requiere un ciclo de desarrollo seguro, alguna forma de patrón de diseño seguro, metodologías de carretera pavimentada ("paved road"), bibliotecas de componentes seguros, herramientas y modelado de amenazas. Comuníquese con sus especialistas en seguridad desde el comienzo y durante todo el proyecto, así como durante su fase de mantenimiento. Considere aprovechar el [Modelo de Madurez para el Aseguramiento del Software (SAMM)](https://owaspsamm.org/) para ayudar a estructurar sus esfuerzos de desarrollo de software seguro. ## Cómo se previene * Establezca y use un ciclo de desarrollo seguro apoyado en Profesionales en Seguridad de Aplicaciones para ayudarlo a evaluar y diseñar la seguridad y controles relacionados con la privacidad. * Establezca y utilice un catálogo de patrones de diseño seguros o componentes de "camino pavimentado" listos para ser utilizados. * Utilice el modelado de amenazas para flujos críticos de autenticación, control de acceso, lógica de negocio y todo clave. * Integre el lenguaje y los controles de seguridad en las historias de usuario. * Integre verificaciones de viabilidad en cada capa de su aplicación (desde el frontend al backend). * Escriba pruebas unitarias y de integración para validar que todos los flujos críticos son resistentes al modelo de amenazas. Recopile casos de uso *y* casos de mal uso para cada capa de la aplicación. * Separe las capas del sistema y las capas de red según las necesidades de exposición y protección. * Separe a los tenants de manera robusta por diseño en todos los niveles. * Limitar el consumo de recursos por usuario o servicio. ## Ejemplos de Escenarios de Ataque **Escenario #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 preguntas y respuestas como evidencia de identidad ya que más de una persona puede conocer las respuestas. Dicho código debe eliminarse y reemplazarse por un diseño más seguro. **Escenario #2:** Una cadena de cines permite descuentos en la reserva de grupos y tiene un máximo de quince asistentes antes de solicitar un depósito. Los atacantes podrían modelar este flujo y probar si podían reservar seiscientos asientos en todos los cines a la vez utilizando unas pocos pedidos, lo que provocaría grandes pérdidas de ingresos. **Escenario #3:** El sitio web de comercio electrónico de una cadena minorista no tiene protección contra bots administrados por revendedores que compran tarjetas de video de alta gama para revender sitios web de subastas. Esto crea una publicidad terrible para los fabricantes de tarjetas de video y los propietarios de cadenas minoristas y una mala sangre duradera con entusiastas que no pueden obtener estas tarjetas a ningún precio. El diseño cuidadoso de anti automatización y las reglas de lógica de negocio, como compras realizadas a los pocos segundos de disponibilidad, pueden identificar compras no auténticas y rechazar dichas transacciones.

súper excelente el curso, ya que podemos ver los dos lados de la versiones como blue team y red team

**Insecure Design** Ocurre cuando creamos una aplicación sin tener en cuenta requerimientos de seguridad. *Ejemplos* 1. Ausencia de requerimientos de seguridad * Ocurre cuando en la arquitectura de software no se tienen en cuenta las buenas prácticas de seguridad. por ejemplo cuando se menciona que el correo ingresado en un login no es correcto, se deben mostrar mensajes informativos más genéricos. 2. Ausencia en control de errores * El no controlar los errores puede mostrar a un atacante mas información de la que se quiere evidenciar. *Impacto* * Altos costos operativos por fallos no controlados *Control* 1. Implementar un ciclo de vida de desarrollo de software seguro 2. Implementar un modelo de madurez de aseguramiento del software

Si quiren saber mas de Owasp Samm <https://owasp.org/www-project-samm/>

😨

creo que deberían ocultar la IP del servidor en la imagen de ejemplo ya que al ingresar si es accesible desde internet y es un IIS 

[Software Development Life Cycle (SDLC)](https://www.synopsys.com/glossary/what-is-sdlc.html) Ciclo de vida del desarrollo de Software S-SDLC Secure Software Develepment Life Cycle

Totalmente de acuerdo.