Security by Design: o que é e como começar (Guia Completo)

Tempo de leitura: 13 minutos

Como Security by Design pode contribuir com a segurança da informação diante do atual cenário tecnológico e as novas regulamentações de privacidade de dados? A medida que acontece a transformação digital nas empresas, a demanda por ferramentas, tecnologias e metodologias de desenvolvimento de softwares só aumenta.

O crescimento de incidentes de segurança, como vazamento de dados, acontece em igual ou superior velocidade. Atualmente, muitas empresas ainda possuem uma abordagem reativa à segurança da informação, sendo necessário o acontecimento de um ataque ou vazamento de dados para considerar práticas proativas como o Security by Design.

O Security by Design é o oposto da segurança reativa, e incorpora boas práticas de segurança da informação para diminuir as vulnerabilidades desde o início do desenvolvimento de software. Propõe uma relação de trabalho positiva entre os desenvolvedores e a equipe de segurança, com requisitos claros e apropriados, além da possibilidade de testar a segurança do código-fonte buscando uma adequação incorporada ao desenvolvimento do software desde seu planejamento inicial e concepção.

A aplicação do Security by Design é abrangente, podendo ter suas práticas aplicadas ao desenvolvimento de software, gerenciamento de riscos, processos internos e no desenvolvimento de novas tecnologias, como por exemplo IoT.

Nesse artigo vamos falar sobre os principais conceitos de Security by Design. Siga a leitura e baixe nosso checklist da OWASP ASVS para verificar se os requisitos de segurança de sua aplicação estão aderentes à função de negócio que desempenha.

Qual a relação entre Desenvolvimento Seguro e Security by Design?

O desenvolvimento seguro surgiu como uma resposta ao crescimento das vulnerabilidades de segurança nos sistemas. Consiste em acrescentar atividades de segurança da informação no ciclo de desenvolvimento de um software. Apresenta uma abordagem estruturada e flexível para implementação imediata, porém muitas equipes de desenvolvimento possuem dificuldades na sua aplicação, principalmente pela falta de conhecimento nas técnicas de segurança.

As equipes se deparam constantemente com a necessidade de gerenciar prazos, novas tecnologias, usabilidade, desempenho e segurança dos sistemas ao mesmo tempo, e sabem que nem sempre é possível atender todos esses requisitos. É necessário compreender que a segurança de sistemas é responsabilidade de todos.

A integração dos requisitos de segurança da informação ao trabalho diário dos desenvolvedores é uma abordagem favorável para que as equipes desenvolvam sistemas mais seguros.

O conceito principal do Shift Left é que é mais eficiente e menos custoso incluir preocupações com segurança e privacidade desde o início do desenvolvimento, reduzindo o volume de vulnerabilidades, retrabalho e, consequentemente, o custo da correção de uma falha no ambiente de produção. Por isso, muitas organizações passaram a incluir um recurso chamado de Security Champion nos times de desenvolvimento, o qual tem a responsabilidade por olhar a segurança durante a esteira.

Nesse contexto, surgiu o conceito de Security by Design, uma abordagem para que o software seja projetado desde a sua fundação para ser seguro.

Benefícios do Security by Design

O conceito de Security by Design quando referenciado a segurança de sistemas, descreve as melhores práticas e padrões de segurança aplicados ao design da arquitetura e, em seguida, usados como princípios orientadores para o time de desenvolvimento. Por isso é considerado uma das principais abordagens para garantir a segurança e a privacidade dos sistemas. Nesta abordagem, a segurança é construída no sistema desde o seu início e começa com um design de arquitetura adequado, levando em consideração os pilares da Segurança da Informação como requisitos.

O Security by Design é considerado uma abordagem eficaz porque considera as práticas maliciosas como verdadeiras e os devidos cuidados são tomados para minimizar o impacto na antecipação de uma vulnerabilidade de segurança. Além desses benefícios, uma boa abordagem de Security by Design proporciona:

Economia: resolver problemas de segurança no início é muito mais eficiente e econômico.

Resiliência: as práticas de Security by Design resultam em um sistema resiliente, em que a segurança é incorporada por padrão ao invés de adicionada às pressas como uma correção.

resultam em um sistema resiliente, em que a segurança é incorporada por padrão ao invés de adicionada às pressas como uma correção. Correção de vulnerabilidades: a implementação de uma variedade de práticas de Security by Design (conscientização, conhecimento, ferramentas e verificações) permite que as falhas de segurança sejam removidas com mais facilidade e rapidez do que testando no final do desenvolvimento.

(conscientização, conhecimento, ferramentas e verificações) permite que as falhas de segurança sejam removidas com mais facilidade e rapidez do que testando no final do desenvolvimento. Adaptação: determinar exatamente quais erros foram cometidos permite adaptar o processo de desenvolvimento para evitar novos erros.

Abaixo descrevemos princípios importantes do Security by Design para o desenvolvimento de software seguro definidos pela OWASP (Open Project Application Security Project).

Os 10 princípios do Security by Design

1. Minimizar a superfície de ataque

O princípio de minimização de superfície de área de ataque é usado para restringir as funções que os usuários têm permissão para acessar, contribuindo com a redução de vulnerabilidades. Com a integração de ferramentas de proteção já existentes, é possível desenvolver um ecossistema de monitoramento e correções em tempo real. Algumas medidas usadas para reduzir a superfície de ataque em servidores e sistemas são:

Implementação e configuração de uma solução de firewall.

Desenvolvimento seguro.

Monitoramento de entrada e saída dos servidores.

Desenvolvimento de recursos de backup para servidores e estações de trabalho.

2. Estabelecimento de padrões

Padrões de desenvolvimento ajudam a entender as implicações de segurança das práticas de desenvolvimento e implantação de código. As orientações a seguir são um começo para que as equipes de desenvolvimento construam softwares resilientes e seguros:

Verificação do acesso ao banco de dados.

Filtragem de campos de entrada do sistema.

Não confiar em validações implementadas no lado do cliente.

Fazer a codificação de resposta.

Evite que navegadores memorizem as informações importantes em formulários.

Verificação de tráfego de informações sigilosas.

Tratamento de erros.

Definição de senhas fortes.

Autenticação dos web services.

3. Princípio do menor privilégio

O princípio do menor privilégio sugere fornecer as permissões necessárias para que um usuário realize suas tarefas, com um tempo determinado e os direitos mínimos estabelecidos. O princípio do menor privilégio é uma estratégia que pode ser incorporado ao Security by Design promovendo a segurança das informações e privacidade. A atribuição de permissões a um usuário pode impedir que ele execute tarefas para as quais não está autorizado, como acessar, obter ou modificar informações. Algumas medidas usadas para definir o princípio do menor privilégio em servidores e sistemas são:

Considerar todos os usuários do sistema como convidados.

Especificar o que é proibido e assim, o restante pode ser permitido.

Qualquer usuário ou objeto tem as permissões básicas para executar as suas tarefas e nenhuma outra a mais.

Definir pontos de estrangulamento no sistema onde tudo será proibido para determinados usuários.

4. Princípio da defesa em profundidade

A defesa em profundidade é um conjunto de práticas que se concentram na proteção, detecção e reação de invasões. Para isso, são usados softwares de segurança e ferramentas para a construção de uma estratégia contra ataques. O uso de ferramentas de segurança como firewalls, antivírus, filtragem de conteúdo, criptografia e controle de acesso colaboram para prevenção de ataques.

5. Falhar com segurança

A manipulação segura de erros é um aspecto importante para uma software seguro e para o Security by Design. Existem dois tipos de erros que merecem destaque:

O primeiro são as exceções que ocorrem no processamento de um controle de segurança.

O outro tipo de exceção relevante à segurança está no código que não faz parte de um controle de segurança.

É importante que essas exceções não permitam comportamentos que o sistema normalmente não permitiria. Um software desenvolvido com segurança deve considerar a existência de três resultados possíveis de um mecanismos de segurança: proibir a operação, permitir a operação ou lançar uma exceção.

6. Não confie nos serviços

Um modelo de confiança zero (conhecido também como Zero Trust) é composto pela recomendação de que as empresas não devem confiar em ninguém ou em nenhum dispositivo ou sistema por padrão e devem verificar todas as conexões antes de permitir o acesso à sua rede. A criação desse modelo foi uma resposta às antigas abordagens de segurança, baseadas na suposição de que a ameaça interna era inexistente e que a segurança da informação deve focar apenas na defesa contra ameaças externas. As ameaças internas são representadas por colaboradores, ex-colaboradores, parceiros de negócio, prestadores de serviços ou qualquer pessoa que tem acesso a informações privilegiadas. As empresas podem levar anos para descobrir a presença dessas ameaças em sua estrutura. Um modelo de confiança zero é composto por:

Conhecimento da arquitetura e infra-estrutura da empresa.

Criação de uma identidade de usuário forte e única.

Desenvolvimento de processos de autenticação.

Monitoramento de serviços e dispositivos.

Definição de políticas de acordo com o valor dos serviços e dados.

Controle de acesso aos serviços e dados.

Não confie na rede, incluindo a rede local.

7. Segregação de funções

A segregação de funções e responsabilidades é o controle de acesso baseado no papel, na atividade ou na função de um usuário dentro de um sistema. A utilização de um perfil por função (ou RBAC – Role Based Access Control) providencia um modelo para administrar privilégios de acessos aos sistemas e infraestrutura de uma empresa. O perfil por função consegue agrupar os acessos, possibilitando uma visão geral dos privilégios e controlando os acessos de uma forma segura para o Security by Design. A implementação de um processo de separação de deveres pode ser composta por:

Definição de regras de segregação de funções aplicáveis ao ambiente.

Criação de matriz de riscos.

Análise de riscos para identificação de violações da segregação de funções.

Análise de atividades conflitantes executadas por usuários alternativos.

Resolução de conflitos que apresentem alto risco.

8. Evitar a segurança por obscuridade

A segurança por obscuridade é quando os desenvolvedores codificam os sistemas de forma secreta acreditando que ninguém será capaz de encontrar as vulnerabilidades do software. O problema com essa técnica é a dependência em relação ao sigilo da implementação do projeto como forma principal de prover segurança para o sistema. Geralmente, as pessoas que fazem uso dessa técnica assumem que o não conhecimento das vulnerabilidades de um software é um indicativo de segurança. Para evitar a segurança por obscuridade é preciso investir em práticas comprovadas para a segurança de sistemas:

Utilização de senhas fortes.

Treinamento e conscientização de equipes.

Princípio do mínimo privilégio possível.

Utilização de softwares de proteção e backup.

9. Mantenha a segurança simples

No início de uma implementação de Security by Design é comum fazer uso de ferramentas, processos e controles em favor da segurança de sistemas, mas é necessário refletir sobre a relevância de todos esses controles, eles acrescentam mais segurança ou burocracia aos sistemas? A existência de muitas ferramentas pode aumentar as brechas de segurança em vez de extingui-las, assim como procedimentos pouco documentados ou falta de automações que podem deixar usuários esperando demais por um acesso. Buscar uma segurança simples e eficaz envolve:

Entender que a segurança de sistemas não envolve apenas tecnologias. Existem políticas, processos e pessoas. Busque por uma postura proativa e não apenas visando o cumprimento de checklists.

Investir em treinamentos e capacitação das equipes de desenvolvimento em boas práticas e comunicar a todas as partes interessadas sobre mudanças no sistema.

Entender os conceitos fundamentais de segurança da informação e buscar por ferramentas e controles adequados a estrutura do sistema.

10. Segurança no processo de manutenção do software

As vulnerabilidades em sistemas precisam ser estudadas pelo time de desenvolvimento para uma correção eficiente mesmo. É preciso entender o comportamento da vulnerabilidade de forma estrutural no sistema e verificar se existem outros componentes que podem ser afetados pela mesma vulnerabilidade.

A falta de um processo ou controle para realizar as correções de problemas pode causar o surgimento de novos problemas e brechas de seguranças nos sistemas. Um processo contínuo de gestão de vulnerabilidades é visto como um aliado para as equipes de desenvolvimento, atuando na identificação, análise, classificação e tratamento das vulnerabilidades. Esse processo busca medir o progresso e avaliar os riscos aos quais os sistemas estão submetidos, colaborando com uma estratégia de Security by Design. As principais etapas de um processo de gestão de vulnerabilidades consistem em:

Mapeamento dos riscos.

Análise e priorização dos riscos.

Definição de responsáveis.

Tratamento das vulnerabilidades.

Treinamento dos times de desenvolvimento.

Produção de relatórios de acompanhamento.

Por onde começar com o Security by Design?

Security by Design começa com a escolha de um modelo e como fazer uso desse modelo de forma correta. Uma em cada três vulnerabilidades encontradas são causadas por um gerenciamento inadequado dos requisitos de segurança dentro de um projeto de software. É importante ter conhecimento das vulnerabilidades dos sistemas e fazer as devidas correções.

A seguir apresentamos algumas das melhores abordagens para implementação do Security by Design, sendo possível combinar diferentes técnicas e desenvolver uma metodologia adaptada às necessidades dos sistemas desenvolvidos pela sua empresa.

Modelagem de Ameaças

A modelagem de ameaças é um processo que busca a identificação de potenciais ameaças e vulnerabilidades estruturais presentes em um software. A modelagem de ameaças é uma atividade fundamental na construção de uma metodologia de Security by Design, com ela é possível reduzir o tempo dedicado ao desenvolvimento do software a longo prazo e erradicar o surgimento de vulnerabilidades de código. Os times de desenvolvimento precisam incluir a modelagem de ameaças nas fases iniciais do seu processo de desenvolvimento se não quiserem dedicar muito esforço para correção de vulnerabilidades.

Este é o cenário ideal para uma abordagem de Security by Design, mas a realidade costuma ser diferente para as equipes. A existência de sistemas legados que são utilizados frequentemente para suportar processos críticos das empresas é um cenário comum. Mesmo em estruturas legadas, a modelagem de ameaças pode ser usada para apresentar uma visão completa dos ativos presentes na estrutura, possibilitando a identificação e classificação da criticidade desses ativos.

Requisitos de Segurança

Um requisito de segurança é uma necessidade que deve ser contemplada por um sistema ou aplicativo, para a identificação de controles de segurança dentro de um processo de desenvolvimento de software seguro. A utilização de requisitos de segurança contribuem para o desenvolvimento e manutenção de um software seguro. É esperado que um software seguro seja capaz de resistir a ataques cibernéticos e recuperar-se diante de uma ameaça materializada.

Existem algumas fontes de conhecimento para a identificação de requisitos de segurança em um processo de desenvolvimento de software seguro. Geralmente, são usados os procedimentos, as políticas e os guias de segurança da informação definidos pela empresa. As conformidades com regulamentações e padrões de segurança exigidos pelo mercado também são considerados nesta etapa. Além disso, existem requisitos de segurança fundamentais para o Security by Design.

Requisitos de Confidencialidade: São definidos ao longo do ciclo de vida da informação, da origem do dado até sua persistência (armazenamento) ou descarte.

Requisitos de Integridade: Buscam garantir a confiabilidade e proteção contra modificações não autorizadas. Um sistema com integridade é quando as modificações ocorrem apenas no cenário projetado de autorização e quando o sistema funciona de acordo como foi projetado.

Requisitos de Disponibilidade: São requisitos relacionados às disciplinas de continuidade de negócios e recuperação de desastres. Esse requisito expõe o software a riscos de destruição de ambientes e interrupção de serviço.

Requisitos de Autenticação: Reúnem elementos para assegurar a legitimidade e validade da identificação apresentada pela entidade requisitante. São utilizadas técnicas de autenticação multifator.

Requisitos de Autorização: São relacionados aos privilégios de uma entidade autenticada. Pode ser aplicado o princípio de privilégio mínimo.

Requisitos de Responsabilidade: Auxiliam na construção do histórico de ações do usuário através de uma trilha de auditoria.

Arquitetura de Segurança

Os elementos da arquitetura de segurança devem ser planejados desde o início do projeto, visando a identificação de informações que precisam ser protegidas contra modificações não autorizadas, fraude, desastres ou divulgação. A utilização da arquitetura de segurança como composição do Security by Design é visto como um desafio, pois é necessário desenvolver arquiteturas capazes de resistir ameaças reais e cumprir normas e regulamentações, além de servir aos negócios e tecnologias da companhia.

A criação de uma estrutura para a arquitetura de segurança permite que a companhia identifique os melhores controles e evolua seus planos. A escolha de um modelo de referência é fundamental para o desenvolvimento dessa estruturação. Dentre os modelos existentes, o TOGAF (The Open Group Architecture Framework) recebe destaque como um modelo de arquitetura conhecido por contribuir com as diferentes áreas da empresa.

O TOGAF descreve um método para definição de uma arquitetura de sistemas como um conjunto de processos, provendo uma lista de padrões recomendados e produtos compatíveis que podem ser usados para implementar os processos. O TOGAF provê uma abordagem global ao design, planejamento, implantação e governança de uma arquitetura corporativa para os negócios, sistemas, dados e tecnologias de uma companhia.

Segurança na Esteira de Desenvolvimento

Para incluir a segurança dentro de um processo de desenvolvimento é necessário enxergar a segurança da informação como mais um requisito do desenvolvimento de software, assim como o desempenho, escalabilidade e usabilidade. Ao incluir atividades de segurança da informação no desenvolvimento de novos sistemas é preciso:

A existência de uma abordagem sistêmica flexível e orientada às práticas ágeis.

A integração com outras atividades relacionadas é fácil.

A estrutura atual de trabalho das equipes é facilmente adaptada.

Resulta em melhorias incrementais de segurança ao projeto.

Atualmente, existem diversas implementações do uso da segurança da informação dentro do desenvolvimento de software e cada implementação oferece benefícios e dificuldades próprias em seu uso. O Microsoft Security Development Lifecycle (SDL) é um modelo robusto e largamente utilizado por equipes de desenvolvimento espalhadas pelo mundo. O Microsoft SDL introduz requisitos de segurança e privacidade ao longo de todas as fases do seu ciclo de vida e possui práticas atualizadas para lidar com cenários de cloud computing, internet das coisas (IoT), inteligência artificial e metodologias ágeis em seu modelo. Os principais processos deste modelo incluem as seguintes atividades:

Desenvolvimento: Organizações como OWASP e CWE disponibilizam informações com as melhores práticas de codificação segura. A equipe de desenvolvimento precisa alinhar o que está sendo desenvolvido com os requisitos de segurança estabelecidos anteriormente na especificação. É indicado o uso de ferramentas de análise de vulnerabilidades em sistemas durante o desenvolvimento para correção imediata de possíveis brechas de segurança.

Teste: São realizados testes dinâmicos de difusão (também conhecidos como fuzz) e são verificados os modelos de ameaças. Testes de invasão e testes de desempenho podem ser usados para ajustar os requisitos finais de segurança antes da entrada do software em ambiente de produção.

Produção: São realizadas revisões nas configurações de servidores e é realizada uma revisão final de segurança junto com a definição de um plano de resposta à incidentes. Um processo de DevSecOps pode ser incluído durante essa etapa. O DevSecOps é uma evolução do modelo DevOps incluindo atividades de segurança, facilitando o desenvolvimento, teste, proteção e distribuição de um software com rapidez e segurança.

Manutenção: A manutenção de um software consiste em descobrir problemas de segurança e aprender com os erros. Uma documentação de causa dos defeitos é desenvolvida para consulta da equipe de desenvolvimento.

Ao longo da implementação desse processo é possível incluir práticas do Privacy by Design ao novo modelo. O Privacy by Design prevê que os sistemas que envolvem o processamento de dados pessoais, devem manter a proteção e a privacidade dos dados durante todo o ciclo de vida da dado. Mesmo aplicativos mais populares passam por problemas relacionadas a privacidade de dados pessoais.

Plataforma GAT (Get Ahead of Threats)

Como vimos, é possível aplicar práticas do Security by Design em novos projetos de desenvolvimento de software como em sistemas legados operacionais. A primeira ação é conhecer profundamente a estruturação de ativos dentro da sua empresa. A plataforma GAT – Get Ahead of Threats possui o recurso de inventário organizacional onde é possível realizar o cadastro de todos os ativos do seu ambiente organizacional que incluem pessoas, IPs, aplicações, Cloud, fornecedores e unidades de negócios. Após esse levantamento inicial, é possível classificar a criticidade de cada ativo de acordo com as características do seu negócio. Em seguida, devem ser realizadas as correções ou mitigação do que traz maior risco cibernético através de um processo de gestão de vulnerabilidades. O GAT permite automação de workflows customizados de processos de gestão em sua plataforma, com a definição de responsáveis pela correção e data limite rastreabilidade, discussões com contexto, upload de evidência e consulta de recomendações para correção. Tudo isso traz maior eficiência e visibilidade ao processos de gestão de Segurança da Informação.

Enquanto as equipes de desenvolvimento codificam novos sistemas ou corrigem vulnerabilidades existentes, a base de conhecimento da plataforma GAT está disponível para consulta e orientação dos desenvolvedores. A nossa base de conhecimento é composta por checklists de boas práticas e normativas de segurança como: OWASP, ISO27001, ISO27701, LGPD, GDPR e PCI-DSS, além de uma base de conhecimento específica sobre vulnerabilidades, recomendação e mitigação que são personalizados de acordo com as necessidades das equipes de desenvolvimento.

Utilize um de nossos checklists e inicie rapidamente com o Security by Design em sua empresa. Organize suas iniciativas de segurança por projetos, criando um projeto específico para modelagem de ameaças, definição de requisitos de segurança e arquitetura de segurança, implantação de um SDLC Seguro e gerenciamento de práticas de segurança com usabilidade. Crie um dashboard específico para acompanhamento em tempo real do progresso do Security by Design por setor e conheça e identifique prontamente as ameaças de segurança da informação relevantes ao seu negócio.

Considerações Finais

Security by Design não é apenas para o desenvolvimento de novos sistemas. É aconselhável realizar verificações de vulnerabilidades em sistemas que não foram desenvolvidos com Security by Design. De forma prática, as equipes podem considerar algumas questões de segurança em seu processo de desenvolvimento:

Existe algum processo falho?

Novas implementações são realmente seguras? O que traz segurança às novas implementações?

Como reduzir o risco em processos e requisitos de software?

Se eu fosse um atacante, como eu poderia ter acesso ao sistema? Como eu poderia explorar falhas existentes?

O conceito de Security by Design quando estendido completamente a empresa contribui para o desenvolvimento de uma cultura segura na qual os colaboradores apoiam suas tarefas e decisões nos princípios da segurança da informação. Disponibilizamos um checklist da OWASP ASVS para você começar hoje mesmo com a construção do Security by Design em sua empresa.