Explicación de la seguridad desde el diseño (SbD)
La seguridad por diseño es un enfoque de desarrollo de software que tiene como objetivo establecer la seguridad como un pilar, no como una idea tardía, es decir, integrar controles de seguridad en los productos de software desde la fase de diseño. SbD crea software seguro que las empresas pueden implementar de inmediato sin incurrir en costos adicionales para las funciones de seguridad.
Para comprender mejor el SbD, imagine un escenario en el que necesita construir un almacén seguro para sus bienes multimillonarios. Podría construir un edificio con madera fácil de romper, fortificarlo con características de seguridad, por ejemplo, sensores y circuito cerrado de televisión, e incluso contratar a una empresa de seguridad. O puede construir su almacén de ladrillo, usar puertas de metal pesado e instalar las mismas características de seguridad.
El almacén de ladrillos será, por supuesto, más seguro, ya que independientemente de sus características de seguridad, es mejor tener un sistema inviolable, y ese es el enfoque que ejemplifica SbD.
The Secure Coding Best Practices [Cheat Sheet]
With curated insights and easy-to-follow code snippets, this 11-page cheat sheet simplifies complex security concepts, empowering every developer to build secure, reliable applications.
Download Cheat Sheet¿Por qué la seguridad desde el diseño?
Las aplicaciones orientadas a la web solían ser vulnerables por diseño (VbD) porque los proveedores de software enviaban software antes de incorporar la seguridad. Esto significaba que las empresas tenían que comprar funciones de seguridad como complementos y parchear las principales vulnerabilidades a medida que surgían, un enfoque rentable para los proveedores, ya que más funciones equivalían a más dinero.
Pero como objetivos principales de los ataques a la cadena de suministro, las empresas son las que se enfrentan a las consecuencias legales, financieras y de reputación cuando se producen infracciones (y a menudo lo hacen).
SbD aborda este problema de "penalizar al usuario empresarial, perdonar al proveedor" mediante la promoción de una cultura de desarrollo de software en la que tanto el usuario como el proveedor son responsables de sus acciones o inacciones. Esto mejora tanto el software de los proveedores como el de los usuarios Postura de seguridad reduciendo su superficie de ataque y facilitando otros resultados clave.
Aplicación de parches más fácil y barata
Aplicar correcciones de seguridad a toda prisa mientras el software está en uso (para evitar violaciones de datos y daños financieros y de reputación asociados) puede ser un dolor de cabeza, costoso y plagado de errores.
Los productos diseñados para ser seguros desde el principio requieren menos parches y menos críticos, lo que hace que el proceso sea mucho más barato y fácil.
Productos rentables
La única forma de proteger los sistemas vulnerables por diseño es agregar varios complementos. Sin embargo, los atacantes aún pueden aprovechar el Puertas traseras creado por la falla VbD para infiltrarse en los sistemas.
Proteger los sistemas de forma predeterminada es más rentable que enfrentarse a un mayor riesgo de filtraciones de datos y sus costes asociados, demandas y multas.
Cumplimiento normativo
Dado que el software desarrollado utilizando el enfoque SbD tiene la seguridad en su núcleo, es más probable que cumpla con la normativa de forma predeterminada. Esto facilita el proceso de verificación de diferentes componentes de software para garantizar conformidad con diversas regulaciones.
¿Cómo funciona la seguridad desde el diseño?
El enfoque SbD tiene cuatro etapas clave, que exploramos a continuación.
Etapa 1: Definir los requisitos de seguridad
SbD comienza con un estudio claro del software que se va a desarrollar, sus posibles vulnerabilidades y los requisitos de seguridad correspondientes. Para un servicio de base de datos, los requisitos de seguridad incluirían cifrado, control de acceso basado en roles (RBAC) y otras técnicas de autorización.
Etapa 2: Realizar evaluaciones de riesgos y modelado de amenazas
Esta etapa implica el uso de un método sensible al contexto Escáner de vulnerabilidades para trazar las posibles rutas de ataque del software.
Por ejemplo, un proveedor de servicios de base de datos está expuesto a posibles rutas de ataque, como direcciones IP públicas o cuentas con privilegios, debido a la información confidencial de identificación personal (PII) y la información de salud protegida (PHI) almacenada en sus bases de datos.
Free Cloud Risk Assessment
Connect with a Wiz expert for a personal walkthrough of the critical risks in each layer of your environment.
Request AssessmentEtapa 3: Escribir código y crear medidas de seguridad simultáneamente
En esta etapa, el equipo de ingeniería abandona los procedimientos de codificación convencionales para desarrollar software con software nativo Medidas de seguridad. Para el proveedor de la base de datos, esto podría incluir la escritura de código que:
Evita que las bases de datos estén abiertas al público de forma predeterminada
Valida automáticamente la entrada del usuario sin que los usuarios de la empresa tengan que comprar complementos
Requiere múltiples mecanismos de autenticación antes de que se conceda cualquier forma de acceso
Limita los puntos de acceso para cuentas con privilegios
Etapa 4: Monitoreo y parcheo continuos
Finalmente, el software se prueba y, si se determina que es seguro por diseño, se envía. A medida que los usuarios implementan el software, el proveedor monitorea, audita y envía continuamente actualizaciones de SbD como nuevas amenazas y Vulnerabilidades emerger.
Principios de seguridad desde el diseño
La Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) anima a los fabricantes de software a adoptar tres principios básicos a la hora de desarrollar un producto.
Responsabilidad compartida
Tanto el proveedor como el cliente deben compartir la carga de la seguridad. Se espera que los fabricantes de software creen productos seguros y parcheen regularmente su software a medida que evoluciona el panorama de amenazas. Mientras tanto, se espera que los clientes configuren sus productos utilizando este software de forma segura y mantengan sus datos seguros.
Transparencia radical
Los fabricantes de software deben compartir información sobre lo que hace que sus productos sean seguros desde el diseño. Son responsables ante sus clientes de los avisos de vulnerabilidad precisos, los registros comunes de vulnerabilidad y exposición (CVE) asociados y los mecanismos de autenticación, por nombrar algunas de las cosas que se esperan de un producto SbD.
Estructura organizativa
SbD requiere el compromiso y la comunicación a nivel de C-suite entre todas las partes interesadas, la colaboración es clave entre proveedores y clientes, así como entre desarrolladores y equipos de seguridad. Esto facilitará la implementación de controles de seguridad casi impenetrables y permitirá la planificación presupuestaria y la asignación de recursos basadas en la información.
Desafíos de la implementación de la seguridad desde el diseño
Analicemos tres de los principales desafíos de la adopción de SbD.
Challenge | Description |
---|---|
Short-term costs vs. long-term profits | The cost of restructuring legacy software and switching programming languages to embed security—rather than bolt it on—is discouraging for most vendors. Even in modern systems, embedding security is a complex and costly process. Still, in the long run, fewer and less complicated patches, fewer attacks, etc. will mean the initial cost pays for itself. |
Marketability | The motivation—for cloud vendors—to implement SbD is low, as there are no direct monetary returns for them. It is difficult to market restructured SbD products on the “now secure-by-design” premise, as this will leave enterprise users with the presupposition that the products weren’t properly built and secured earlier on. It is easier to sell legacy software as is, alongside aftersales/add-on security products like firewalls and antivirus. |
Third-party vendor liability | An important implication of SbD is that software vendors are liable for supply chain vulnerabilities. For example, a single security flaw can affect several enterprise customers who would want the vendor to take the blame, i.e., face the financial and reputational consequences. Getting all parties onboard with the shared responsibility model is thus critical, as discussed above. This makes it clear that security is in fact a shared burden between the vendor and the customer. |
Prácticas recomendadas de seguridad desde el diseño
CISA ofrece algunas tácticas de SbD extraídas de la Marco de desarrollo de software seguro (SSDF) del Instituto Nacional de Estándares y Tecnología (NIST, por sus siglas en inglés): SP 800-218. Las organizaciones deben integrar estas prácticas en cada etapa de su ciclo de vida de desarrollo de software (SDLC).
Utilizar componentes de software seguros
Implemente componentes de software bien protegidos, incluidas bibliotecas, marcos y middleware, solo de proveedores verificados. Además, evite el software con vulnerabilidades conocidas, incluidos errores criptográficos y de autenticación, controles de acceso rotos, vulnerabilidades de inyección y problemas de registro.
Una plataforma de protección de aplicaciones nativa de la nube (CNAPP) será útil para detectar componentes no seguros.
Adoptar buenas prácticas de diseño
Las organizaciones pueden reducir el riesgo para sus sistemas de software mediante la implementación de la defensa en profundidad, es decir, Tener más de una capa de medidas de seguridad. Mientras tanto, el sandboxing aísla el software y los componentes de seguridad para evitar que el compromiso de un solo componente afecte a todo el sistema.
Los proveedores también deben diseñar software que facilite la aplicación de parches; Minimizar el tiempo de inactividad resultante de las actualizaciones de software alentará a los usuarios empresariales a aplicar parches más rápido.
Utilizar lenguajes de programación seguros para la memoria
El NIST anima a Desarrolladores para implementar mitigaciones comunes dirigidas a la memoria, como la integridad del flujo de control (CFI) y la aleatorización del diseño del espacio de direcciones (ASLR). Pero más allá de esto, el NIST también señala que deberían adoptar lenguajes modernos seguros para la memoria, por ejemplo, Rust, Go, Java, C#, Swift y Python, evitando al mismo tiempo sus homólogos inseguros para la memoria, C y C++.
Esto ayudará a mitigar vulnerabilidades de seguridad de memoria como SlammerWorm, Ghost Engine y Stagefright.
Adopción de consultas parametrizadas y marcos de plantillas web
Las consultas con parámetros son consultas SQL con parámetros que separan la entrada del usuario de la propia consulta. Los marcos de plantillas web contienen información contextual que evita automáticamente las entradas sospechosas del usuario. Juntos, estos mecanismos ayudan a prevenir la inyección de código SQL y Ataques de secuencias de comandos entre sitios (XSS).
Proporcionar SBOM
Los proveedores de software deben proporcionar a los usuarios una lista de los componentes, bibliotecas y herramientas de software propietarios y de terceros que utilizaron para desarrollar software. Esta lista, que se puede generar a través de un escáner SBOM sin agente: permite una fácil resolución de vulnerabilidades.
Elimine las contraseñas predeterminadas
Los proveedores deben evitar lanzar productos con contraseñas predeterminadas. En su lugar, deben adoptar la autenticación multifactor y exigir a los usuarios que establezcan contraseñas seguras inmediatamente después de configurar el software.
Proporcionar perfiles de autorización de software
Estos perfiles designan roles de usuario y casos de uso para limitar el acceso innecesario a los datos de usuario y las cuentas con privilegios. Los fabricantes de software deben proporcionar perfiles de autorización de software detallados, implementar el principio de privilegio mínimo y emitir advertencias contra el desvío de los límites designados.
Conclusión
La seguridad desde el diseño implementa de forma proactiva los protocolos de seguridad desde la etapa de diseño del software. Liderado por CISA y otros actores clave de la industria, SbD fomenta la realización de evaluaciones de vulnerabilidades, análisis de rutas de ataque y análisis de componentes de software para determinar y resolver posibles vulnerabilidades de software antes de que se envíen las aplicaciones y en cada etapa del SDLC.
El objetivo es eliminar las costosas herramientas de seguridad complementarias y los complicados cambios en el código posventa que no protegen adecuadamente los sistemas de los ataques porque ya son vulnerables por diseño.
SbD es un enfoque más barato, rápido y sólido para crear y proteger aplicaciones. Esta es la razón por la que Wiz es uno de los principales defensores de Código de seguridad de envío. Su solución:
Facilita la visibilidad del software de extremo a extremo
Proporciona SBOM actualizados
Permite Análisis de la ruta de ataque
Regístrese para un Demostración personalizada para ver cómo Wiz puede ayudarte a comenzar tu viaje hacia los productos seguros por diseño.
See for yourself...
Learn what makes Wiz the platform to enable your cloud security operation