Segurança por design (SbD) explicada
A segurança por design é uma abordagem de desenvolvimento de software que visa estabelecer a segurança como um pilar, não uma reflexão tardia, ou seja, integrar controles de segurança em produtos de software desde a fase de design. A SbD cria software seguro que as empresas podem implantar imediatamente sem incorrer em custos adicionais para recursos de segurança.
Para entender melhor o SbD, imagine um cenário em que você precisa construir um armazém seguro para seus produtos multimilionários. Você pode construir um prédio com madeira fácil de quebrar, fortalecê-lo com recursos de segurança, por exemplo, sensores e CFTV, e até mesmo contratar uma empresa de segurança. Ou você pode construir seu armazém de tijolos, usar portas de metal pesado e instalar os mesmos recursos de segurança.
O armazém de tijolos será, é claro, mais seguro, pois não importa seus recursos de segurança, é melhor ter um sistema inviolável, e essa é a abordagem que exemplifica o 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 que segurança por design?
Os aplicativos voltados para a Web costumavam ser vulneráveis por design (VbD) porque os fornecedores de software enviavam software antes de incorporar segurança nele. Isso significava que as empresas tinham que comprar recursos de segurança como complementos e corrigir as principais vulnerabilidades à medida que surgiam – uma abordagem lucrativa para os fornecedores, pois mais recursos equivaliam a mais dinheiro.
Mas, como os principais alvos dos ataques à cadeia de suprimentos, as empresas são as que enfrentam as consequências legais, financeiras e de reputação quando ocorrem violações (e geralmente acontecem).
O SbD aborda esse problema de "penalizar o usuário corporativo, poupar o fornecedor" promovendo uma cultura de desenvolvimento de software em que tanto o usuário quanto o fornecedor são responsabilizados por suas ações ou omissões. Isso melhora o software dos fornecedores e usuários Postura de segurança reduzindo sua superfície de ataque e facilitando outros resultados importantes.
Aplicação de patches mais fácil e barata
Aplicar correções de segurança com pressa enquanto o software está em uso (para evitar violações de dados e danos financeiros e de reputação associados) pode ser uma dor de cabeça, cara e repleta de erros.
Os produtos projetados para serem seguros desde o início exigem menos e menos patches críticos, tornando o processo muito mais barato e fácil.
Produtos econômicos
A única maneira de proteger sistemas vulneráveis por design é adicionar vários complementos. No entanto, os invasores ainda podem aproveitar o backdoors criado pela falha VbD para se infiltrar nos sistemas.
Proteger sistemas por padrão é mais econômico do que enfrentar um risco maior de violações de dados e seus custos, ações judiciais e multas associados.
Conformidade regulatória
Como o software desenvolvido usando a abordagem SbD tem a segurança em seu núcleo, é mais provável que ele seja compatível por padrão. Isso facilita o processo de verificação de diferentes componentes de software para garantir conformidade com vários regulamentos.
Como funciona a segurança por design?
A abordagem SbD tem quatro estágios principais, que exploramos abaixo.
Estágio 1: Definir requisitos de segurança
O SbD começa com um estudo claro do software a ser desenvolvido, suas vulnerabilidades potenciais e os requisitos de segurança correspondentes. Para um serviço de banco de dados, os requisitos de segurança incluiriam criptografia, RBAC (controle de acesso baseado em função) e outras técnicas de autorização.
Estágio 2: Realizar avaliações de risco e modelagem de ameaças
Esta etapa envolve o uso de um scanner de vulnerabilidade para mapear os possíveis caminhos de ataque do software.
Por exemplo, um provedor de serviços de banco de dados está exposto a possíveis caminhos de ataque, como IPs públicos ou contas privilegiadas, devido a informações confidenciais de identificação pessoal (PII) e informações de saúde protegidas (PHI) armazenadas em seus bancos de dados.
Free Cloud Risk Assessment
Connect with a Wiz expert for a personal walkthrough of the critical risks in each layer of your environment.
Request Assessment
Estágio 3: Escrever código e criar medidas de segurança simultaneamente
Nesta etapa, a equipe de engenharia descarta os procedimentos convencionais de codificação para desenvolver software com Medidas de segurança. Para o provedor de banco de dados, isso pode incluir escrever código que:
Impede que os bancos de dados sejam abertos ao público por padrão
Valida automaticamente a entrada do usuário sem que os usuários corporativos precisem comprar complementos
Requer vários mecanismos de autenticação antes que qualquer forma de acesso seja concedida
Limita os pontos de acesso para contas privilegiadas
Estágio 4: Monitorar e corrigir continuamente
Finalmente, o software é testado e, se for considerado seguro por design, enviado. À medida que os usuários implantam o software, o fornecedor monitora, audita e envia continuamente atualizações de SbD como novas ameaças e Vulnerabilidades emergir.
Princípios de segurança por design
A Agência de Segurança Cibernética e Infraestrutura (CISA) incentiva os fabricantes de software a adotar três princípios básicos ao desenvolver um produto.
Responsabilidade compartilhada
Tanto o fornecedor quanto o cliente deve compartilhar o fardo da segurança. Espera-se que os fabricantes de software criem produtos seguros e corrijam regularmente seus softwares à medida que o cenário de ameaças evolui. Enquanto isso, espera-se que os clientes configurem seus produtos usando este software com segurança e mantenham seus dados seguros.
Transparência radical
Os fabricantes de software devem compartilhar informações sobre o que torna seus produtos seguros por design. Eles são responsáveis perante seus clientes por avisos de vulnerabilidade precisos, os registros de vulnerabilidade e exposição comuns (CVE) associados e mecanismos de autenticação, para citar algumas das coisas esperadas de um produto SbD.
Estrutura organizacional
O SbD requer comprometimento e comunicação em nível de C-suite entre todas as partes interessadas, a colaboração é fundamental entre fornecedores e clientes, bem como desenvolvedores e equipes de segurança. Isso facilitará a implementação de controles de segurança quase impenetráveis e permitirá o planejamento orçamentário baseado em insights e a alocação de recursos.
Desafios da implementação da segurança por design
Vamos discutir três principais desafios da adoção do 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áticas recomendadas de segurança por design
A CISA oferece algumas táticas de SbD retiradas do Estrutura de Desenvolvimento de Software Seguro (SSDF) do Instituto Nacional de Padrões e Tecnologia (NIST): SP 800-218. As organizações devem integrar essas práticas em todas as etapas de seu ciclo de vida de desenvolvimento de software (SDLC).
Use componentes de software seguros
Implante componentes de software bem protegidos, incluindo bibliotecas, estruturas e middleware, apenas de provedores verificados. Além disso, evite software com vulnerabilidades conhecidas, incluindo falhas criptográficas e de autenticação, controles de acesso quebrados, vulnerabilidades de injeção e problemas de registro.
Uma plataforma de proteção de aplicativos nativa da nuvem (CNAPP) será útil para detectar componentes não seguros.
Adote boas práticas de design
As organizações podem reduzir o risco para seus sistemas de software implementando a defesa em profundidade, ou seja, ter mais de uma camada de medidas de segurança. Enquanto isso, o sandboxing isola o software e os componentes de segurança para evitar que o comprometimento de um único componente afete todo o sistema.
Os fornecedores também devem projetar software que facilite a aplicação de patches; Minimizar o tempo de inatividade resultante de atualizações de software incentivará os usuários corporativos a aplicar patches mais rapidamente.
Utilize linguagens de programação seguras para memória
NIST incentiva Desenvolvedores para implementar mitigações comuns direcionadas à memória, como CFI (integridade do fluxo de controle) e ASLR (randomização de layout de espaço de endereço). Mas, além disso, o NIST também observa que eles devem adotar linguagens modernas de memória segura, por exemplo, Rust, Go, Java, C#, Swift e Python, evitando suas contrapartes inseguras de memória, C e C++.
Isso ajudará a mitigar vulnerabilidades de segurança de memória, como SlammerWorm, Ghost Engine e Stagefright.
Adote consultas parametrizadas e estruturas de modelo da Web
Consultas parametrizadas são consultas SQL com parâmetros que separam a entrada do usuário da própria consulta. As estruturas de modelo da Web contêm informações contextuais que impedem automaticamente a entrada suspeita do usuário. Juntos, esses mecanismos ajudam a evitar a injeção de SQL e ataques de script entre sites (XSS).
Fornecer SBOMs
Os fornecedores de software devem fornecer aos usuários uma lista dos componentes, bibliotecas e ferramentas de software proprietários e de terceiros que usaram para desenvolver software. Essa lista, que pode ser gerada por meio de um Scanner de SBOM sem agente— permite uma fácil resolução de vulnerabilidades.
Elimine senhas padrão
Os provedores devem evitar lançar produtos com senhas padrão. Em vez disso, eles devem adotar a autenticação multifator e exigir que os usuários definam senhas fortes imediatamente após configurar o software.
Fornecer perfis de autorização de software
Esses perfis designam funções de usuário e casos de uso para limitar o acesso desnecessário a dados de usuário e contas privilegiadas. Os fabricantes de software devem fornecer perfis detalhados de autorização de software, implementar o princípio do privilégio mínimo e emitir avisos contra o desvio dos limites designados.
Conclusão
A segurança por design implementa proativamente protocolos de segurança desde o estágio de design de software. Defendido pela CISA e outros participantes importantes do setor, o SbD incentiva a realização de avaliações de vulnerabilidade, análise de caminho de ataque e análise de componentes de software para determinar e resolver possíveis vulnerabilidades de software antes que os aplicativos sejam enviados e em todas as etapas do SDLC.
O objetivo é eliminar ferramentas de segurança caras e alterações complicadas de código pós-venda que não protegem adequadamente os sistemas contra ataques porque já são vulneráveis por design.
O SbD é uma abordagem mais barata, rápida e robusta para criar e proteger aplicativos. É por isso que Wiz é um dos principais defensores de Código seguro de envio. Sua solução:
Facilita a visibilidade completa do software
Fornece SBOMs atualizados
Permite Análise do caminho de ataque
Inscreva-se para um demonstração personalizada para ver como a Wiz pode ajudá-lo a iniciar sua jornada para produtos seguros por design.
See for yourself...
Learn what makes Wiz the platform to enable your cloud security operation
