0
0
A segurança é um grande negócio, e as empresas são as únicas a arcar com o custo.
Todos os dias, parece que lemos outra manchete sobre uma grande violação de dados que afeta as principais organizações e as muitas pessoas que elas servem. Como resultado dessas violações, sites como haveibeenpwned.com fornecem informações pesquisáveis sobre muitas das maiores violações da Internet . Quando ocorre uma violação de grandes dados, as organizações sofrem grandes perdas, tanto financeiramente quanto em reputação.
Estado atual – o sanduíche de segurança
Apesar dos riscos conhecidos de violações de segurança, o padrão atual de segurança em nosso setor é subótimo, principalmente durante o processo de atualização ou fornecimento de um novo recurso de tecnologia. As equipes geralmente fazem muito planejamento e análise antes do desenvolvimento e após a entrega de um recurso. Em alguns casos, os testadores de penetração verificam vulnerabilidades durante o processo; no entanto, é menos comum que os processos de segurança existam durante o processo de desenvolvimento real.
Apesar dos riscos conhecidos de violações de segurança, o padrão atual de segurança em nosso setor é subótimo.
Chamamos isso de “sanduíche de segurança” – muitos planejamentos e discussões iniciais sobre segurança, além de testes e correções pós-desenvolvimento, mas sem segurança no meio.
O sanduíche de segurança é arriscado por vários motivos:
- O design, o planejamento e as implementações de recursos são feitos sem a segurança em mente;
- O processo para capturar vulnerabilidades não foi aprimorado;
- As equipes não compartilham a responsabilidade pela segurança; e
- Se ocorrer um incidente, talvez você não consiga se recuperar rapidamente.
Como um processo ágil afeta a segurança?
A natureza rápida e perturbadora dos ciclos de negócios atuais significa que as organizações devem incorporar processos ágeis para permanecerem competitivas. De fato, mais e mais empresas seguem o conceito de Entrega Contínua, descrito pela primeira vez no livro homônimo de 2010, co-escrito pelos ex-alunos da ThoughtWorks, Jez Humble e David Farley. Mas a segurança não foi inicialmente incluída no modelo. Acreditamos que isso deve mudar.
A segurança ocupa um lugar importante no processo ágil devido aos riscos extremos que uma violação representa para a organização. Considere o modelo de Entrega Contínua abaixo:
Quando uma equipe incorpora segurança ao longo de seu processo ágil, os benefícios obtidos são semelhantes às qualidades adquiridas pela incorporação contínua de outras práticas. Esses benefícios incluem o seguinte:
- Maior confiança no que é liberado na produção;
- A capacidade de fazer alterações com sucesso em uma base micro;
- Melhores testes e planejamento; e
- Uma reação mais rápida para fazer melhorias ou correções.
Os controles de segurança proativos da OWASP recomendam verificar a segurança com antecedência e frequência, em vez de confiar nos testes de penetração no final de um processo para detectar bugs. Isso ocorre porque a última abordagem é propensa a não encontrar todas as possíveis vulnerabilidades, um processo manual, e dificulta a capacidade de lançar software cedo e frequentemente. Além disso, esperar até que um recurso tenha sido desenvolvido para testar erros também aumenta o custo e o tempo para liberar o produto em produção, pois esse bug deve ser devolvido à equipe de desenvolvimento para ser corrigido antes do lançamento.
Criando segurança na linha do tempo ágil
Em um nível alto, um projeto típico de entrega de software ágil no ThoughtWorks consiste em várias etapas que podem ser organizadas em três fases distintas: descoberta, criação e entrega. Cada etapa é descrita em mais detalhes abaixo.
1.Discovery: Qual é o estado atual?
O objetivo da fase de descoberta é entender o estado atual do sistema. As informações que podem ser coletadas nesta fase incluem:
- Uma lista de sistemas / aplicativos existentes, seus usuários e pessoas envolvidas nesses sistemas
- Um mapa de como os sistemas existentes se comunicam
- Um mapa do caminho atual para a produção
- Uma revisão de incidentes / ataques passados, a fim de evitar recorrências no futuro
- Uma revisão das políticas de segurança existentes e como elas impactarão o escopo do projeto
Esta informação pode então ser usada para informar decisões nas seguintes fases.
2.Iniciação / Kickoff do Projeto: O que as equipes precisam proteger?
O objetivo da fase inicial do projeto é entender o seguinte:
- O que será construído
- Quais pessoas ou serviços devem estar envolvidos
- Quais ativos precisam ser protegidos
- Como os invasores podem comprometer o sistema
- Como ameaças em potencial podem ser priorizadas e mitigadas
É vital que essa conversa continue durante todo o processo de desenvolvimento, à medida que o produto evolui, de modo a garantir a segurança correta ao longo do processo.
O que será construído?
No final do início do projeto, sua equipe deve começar a criar diagramas de arquitetura de alto nível e definir limites de confiança dentro desses diagramas. As equipes não precisam de um contrato API refinado ou da pilha de tecnologia completa desde o início, mas devem ter uma idéia dos principais componentes e interações entre eles. Por exemplo, se estamos construindo um novo site de comércio eletrônico, sabemos que haverá uma interface do usuário com a qual o usuário final interagirá, um conjunto de serviços em que a lógica comercial residirá e um armazenamento de dados. Com base em projetos anteriores, também podemos fazer algumas suposições iniciais sobre onde esse componente residiria inicialmente (ou seja, internamente no datacenter corporativo ou externamente na nuvem).
À medida que progredimos no desenvolvimento, algumas dessas suposições serão válidas, outras não, e é importante atualizar esse modelo regularmente, pois os limites de confiança mudarão com o tempo. Um limite de confiança é onde os dados são movidos de uma fonte menos confiável para um sistema mais confiável. Um exemplo de limite de confiança é quando um usuário envia um formulário, pois os dados estão passando de um ambiente controlado pelo usuário para um ambiente confiável (nosso servidor). Onde quer que os dados se movam através de um limite de confiança, é um bom lugar para se concentrar em tomar medidas como modelar ameaças ou codificar validações.
Em suma, ao final desse processo, uma equipe deve ter a estrutura inicial de uma arquitetura de alto nível e um entendimento dos limites de confiança nessa arquitetura .
Qual é o cenário atual de ameaças?
Um ditado comum em segurança é que “você não pode proteger o que não entende”. Como resultado, é aconselhável, durante o início do projeto, enumerar os atores (pessoas, recursos e serviços envolvidos no sistema) , ativos (itens de valor) e atacantes envolvidos, bem como metas de ataque e possíveis vetores que possam comprometer seu sistema.
A modelagem de ameaças e as árvores de ataque podem ser ferramentas úteis para identificar ameaças e aumentar a visibilidade. Recomendamos avaliar primeiro como as ameaças de segurança comunspode ser relevante para o projeto, usando a modelagem de ameaças como uma ferramenta para identificar ameaças exclusivas ao projeto e ao domínio comercial. Por exemplo, se o projeto for um aplicativo da web, primeiro considere as vulnerabilidades comuns inerentes aos aplicativos da web em geral e, em seguida, use a modelagem de ameaças para identificar e atenuar as vulnerabilidades específicas do seu domínio, base de usuários etc.
O que você pode fazer sobre coisas que podem dar errado?
Quando existe uma ameaça ao seu sistema, a solução ideal é mitigar, eliminar ou transferir a ameaça. Por exemplo, se uma ameaça ao sistema é que a senha de um usuário pode ser adivinhada por meio de um ataque de força bruta, uma atenuação a essa ameaça pode incluir a autenticação multifatorial ou bloquear um usuário após várias tentativas com falha.
Essas etapas nem sempre estão disponíveis, e a empresa deve assumir o risco depois de avaliar o custo e o impacto potencial da ameaça. Por exemplo, a engenharia social é uma ameaça difícil de mitigar completamente, pois isso geralmente está no controle do usuário. Portanto, algumas ameaças devem ser aceitas, mas sua equipe deve ter infraestrutura suficiente para detectar comprometimentos e recuperar-se rapidamente com o mínimo de dano duradouro. Para conseguir isso, verifique se você possui backups regulares de dados, log robusto em pelo menos dois locais separados e um pipeline de construção seguro e eficaz.
3. Entrega: Qual é o melhor cenário para um processo de entrega seguro?
Embora cada processo de negócios seja diferente, existem maneiras de identificar onde boas práticas de segurança podem ser incorporadas continuamente. Abaixo, está um resumo de cada etapa do ciclo de vida do agile story:
Iteração 0: configuração do ambiente
A maioria dos projetos começa com uma “Iteração 0”, quando a infraestrutura necessária é estabelecida antes da entrega dos recursos.
Os ambientes de pré-produção fornecem um ponto de entrada para destinos mais valiosos, e é por isso que as equipes devem incorporar maiores medidas de segurança em todo o pipeline de construção. As fraquezas exploráveis nos ambientes de pré-produção são frequentemente ignoradas, como configurações padrão perigosas ou privilégios desnecessários. Os serviços geralmente têm senhas padrão ou estão configurados para serem acessíveis sem autenticação e, portanto, são alvos fáceis. Por exemplo, o Redis por padrão está acessível sem autenticação . Embora as equipes possam atenuar esses riscos nos ambientes de produção, a pré-produção costuma ser vista como menos arriscada e esse tipo de vulnerabilidade pode ser esquecido – criando pontos de acesso para os atacantes.
Ao configurar ambientes de desenvolvimento, verifique se seus serviços estão configurados para seguir as instruçõesPrincípio do Menor Privilégio , no qual o acesso a informações ou serviços é concedido apenas a pessoas que têm uma necessidade legítima das informações. Como parte disso, revise as definições de configuração dos serviços (como o servidor de IC) nos ambientes de produção e desenvolvimento.
A iteração 0 também é uma boa oportunidade para começar a adicionar ferramentas e práticas de segurança proativas ao seu pipeline de desenvolvimento. O SecDevOps (geralmente chamado de Rugged) é uma prática emergente que enfatiza isso, e veremos muito movimento nisso no futuro. Recomendamos começar com ferramentas comprovadas que forneçam um comportamento confiável em seu pipeline, como o OWASP Dependency Check .
Por fim, ter um pipeline de construção otimizado e consistente ajudará a liberar com segurança as correções encontradas na produção. O plano de lançamento do “chemspill” do Firefox é um bom modelo de infraestrutura suficiente para recuperar-se de forma rápida e confiável de uma vulnerabilidade.
Ciclo de vida da história
Histórias de usuários são a base de qualquer desenvolvimento ágil. Normalmente, no início de um projeto, a equipe se senta e concorda em como essas histórias se moverão ao longo da parede. Este guia simples também pode conter critérios de segurança que as histórias precisam atender para que possam ser consideradas completas.
Pronto para o desenvolvimento
Uma história pode ser definida como ‘Pronto para o desenvolvimento’ se uma equipe tiver identificado e analisado os requisitos de segurança exclusivos envolvidos nessa história.
Por exemplo, se a história envolver a coleta de dados do usuário, uma questão a ser considerada é como essas informações são tratadas com segurança na história. Alguma dessas PII (informações de identificação pessoal)? Existem convenções estabelecidas para lidar com dados de uso confidenciais?
As equipes devem escrever critérios de aceitação que contenham informações sobre o nível de segurança que precisa ser considerado na história. Um bom exemplo é a forma como tratamos usuários não autorizados ou não autenticados é o seguinte:
Dado um usuário não autenticado entra no sistema
Quando ela tenta perfil dela
Entãoela é redirecionada para a página de login.
Percebemos que nem tudo pode ser escrito como critério de aceitação, mas ainda queremos garantir que os desenvolvedores e os QAs os levem em consideração ao trabalhar na história. Eles também podem ser identificados nos requisitos multifuncionais (CFRs) de um projeto, juntamente com outros, como desempenho e usabilidade.
Exemplos de requisitos multifuncionais podem incluir requisitos para registro seguro e informativo e tratamento de erros ou uso de controles do navegador. Especificamente, um critério pode ser o envio de cabeçalhos para ativar a proteção do navegador contra ataques comuns. Um bom lugar para começar é a Folha de Dicas do Top 10 da OWASP .
Em desenvolvimento
Enquanto os desenvolvedores de software estão implementando um recurso, tanto o pensamento quanto os testes de segurança devem permanecer fortemente enraizados da mesma maneira que o Desenvolvimento Orientado a Testes se entrelaçou no ciclo de vida do desenvolvimento para garantir a qualidade do software.
Como é a segurança contínua ao implementar um recurso? Semelhante à implementação de outros Requisitos Funcionais Cruzados e critérios de aceitação do usuário, os desenvolvedores devem implementar o recurso com os requisitos de segurança em mente. Além disso, os desenvolvedores devem ter em mente o modelo de ameaça existente do sistema, bem como um padrão de segurança de linha de base no qual as soluções para ameaças comuns sejam bem compreendidas (como o Top 10 da OWASP).
Por exemplo, se um recurso envolver a gravação de uma nova consulta em uma fonte de dados, um par de desenvolvedores deve estar ciente das ameaças comuns existentes e como lidar com elas. Podem ser consultas a um banco de dados SQL que devem ser parametrizadas para reduzir a injeção de SQL. Ou se o modelo de ameaça de um sistema incluir a proteção de dados de usuários altamente confidenciais, os desenvolvedores revisarão como esses dados são armazenados, criptografados e acessados durante a implementação de um recurso.
No processo de desenvolvimento, as equipes também podem escrever testes automatizados com base nos critérios de segurança identificados, como o uso de um teste de jornada do usuário para validar o comportamento pretendido, se um usuário não privilegiado tentar acessar informações privilegiadas.
Pronto para teste
Os desenvolvedores sabem que a história está pronta para uma rodada de processo de controle de qualidade quando as seguintes etapas forem concluídas:
- O sistema atende aos critérios de aceitação
- Os CFRs foram levados em consideração e implementados como parte da história, se necessário
- Convenções de código estabelecidas foram atendidas
As equipes normalmente concordam com as convenções de código que as ajudam a criar um processo consistente e fácil para manter o código. Como as equipes lidam com a segurança deve fazer parte dessas convenções. Por exemplo, a equipe deve concordar sobre onde e como usar as validações no servidor quando os dados são enviados através de um limite de confiança – mesmo que esses dados tenham sido validados no lado do cliente.
Em teste
O processo de controle de qualidade é um bom ponto no processo de desenvolvimento para validar os requisitos de segurança. Especificamente, o processo de controle de qualidade da sua equipe pode incorporar a verificação contra árvores de ataque, CFRs e critérios de aceitação de segurança identificados.
A segurança também pode ser incorporada ao código retrospectivo. Se sua equipe seguir as práticas de XP, um par de desenvolvedores (ou QAs) deve ter trabalhado a história e feito constantes revisões por pares. No entanto, é importante compartilhar esse conhecimento com o restante da equipe. Na maioria dos nossos projetos, as equipes dedicam tempo todas as semanas a revisões de código. Nessas sessões, toda a equipe técnica discute as implementações e os padrões introduzidos durante a semana, fornece feedback e sugere melhorias. Essas sessões também podem incluir como a história foi implementada do ponto de vista da segurança.
Produção
Depois que um recurso entra em produção, é importante garantir que haja uma infraestrutura de monitoramento suficiente para detectar ataques e comprometimentos. Para isso, são importantes as ferramentas de agregação de log e monitoramento de rede ELK , Splunk , LogWatch ou fail2ban .
Além disso, é vital desenvolver um plano de resposta a incidentes suficiente, caso um invasor tenha êxito em comprometer seu sistema. Este plano de resposta deve considerar como notificar qualquer usuário impactado, um plano de escalação interno e como garantir que essa vulnerabilidade não ocorra novamente no futuro.
Da mesma forma, é uma boa prática manter um registro das decisões arquitetônicas e técnicas tomadas no projeto para referência futura. Isso inclui documentar ataques e incidentes para que uma equipe possa aprender com eles e aplicar as descobertas nos projetos atuais ou futuros.
Melhoria continua
Como em qualquer processo ágil, as equipes podem aprender e melhorar de maneira iterativa. Especificamente, as equipes devem atualizar continuamente seu modelo de ameaças e atacar árvores à medida que cresce o conhecimento sobre o produto, os sistemas que estão sendo construídos e a interação entre os usuários e esses sistemas.
Também recomendamos a colaboração contínua entre uma equipe de desenvolvimento e uma equipe de segurança ou testador de penetração durante todo o processo de desenvolvimento, não apenas no final do desenvolvimento de um recurso e antes da liberação para produção. Por exemplo, um testador de penetração pode participar de reuniões de planejamento de iteração ou trabalhar com equipes para identificar requisitos para critérios de aceitação. Com essa abordagem, podemos evitar o teste de “derrubar o muro” e, idealmente, eliminar bugs antes que o recurso seja desenvolvido.
Avançando: com o que começar
Pela nossa experiência, pode ser assustador para as equipes decidir por onde começar depois de ouvir uma longa lista de práticas recomendadas. Fazer qualquer coisa, exceto 100%, pode parecer um fracasso, mas a barra pode parecer impossivelmente alta. Aqui, recomendamos que as equipes comecem com práticas pequenas e de alto impacto, iterem e evoluam.
1. Desenvolva convenções de código para controles proativos da OWASP .
É útil ter um plano de como mitigar proativamente as vulnerabilidades gerais, pois os atacantes geralmente começam a atacar um sistema pesquisando as vulnerabilidades mais comuns usando ferramentas amplamente disponíveis, como ZAP ou Metaspoit. Além disso, recomendamos seguir mitigações bem compreendidas quando possível, pois isso reduz a imprevisibilidade e os erros possivelmente imprevistos na implementação.
2. Tenha critérios de aceitação de segurança em histórias relevantes.
Se houver critérios de segurança exclusivos para os recursos que não são cobertos por requisitos multifuncionais (CFRs), recomendamos capturar esses critérios em histórias e validá-los no processo de controle de qualidade.
3. Tenha um plano de resposta a incidentes.
Sua equipe deve identificar 1) quem deve estar envolvido na correção; 2) quem dentro da organização deve ser notificado sobre a violação; 3) quando e como os usuários devem ser notificados. Além disso, todos na equipe e potencialmente envolvidos devem estar cientes desse plano e entender seus papéis e responsabilidades.
4. Crie segurança no seu pipeline.
Um bom lugar para começar é automatizar as práticas recomendadas de segurança em seu pipeline. As ferramentas de análise estática e dinâmica podem ajudar a identificar vulnerabilidades que foram perdidas durante o desenvolvimento e o teste. A verificação automatizada de bibliotecas que precisam ser atualizadas também é bastante simples de incluir como verificação automática de pipeline. Lembre-se de que sua equipe deve ter um plano de como atualizar dependências externas quando necessário.
Em que crescer
1. Modelagem de ameaças
Pode levar tempo para aprender a identificar minuciosamente os possíveis furos em um sistema. Primeiro, estabeleça um padrão de segurança de linha de base a partir de padrões estabelecidos, como o ASVS , e use a modelagem de ameaças como uma ferramenta para identificar vulnerabilidades adicionais exclusivas do sistema.
2. Boa cultura de segurança
Em geral, o objetivo deve ser a segurança como parte do processo e da cultura cotidianos de uma equipe, semelhante ao movimento de incorporação do TDD (Test Driven Development) e DevOps em uma prática contínua. A negligência na segurança pode ter consequências catastróficas e, quanto mais as equipes incorporarem boas práticas de segurança no fluxo de trabalho diário de nossa equipe, melhor ela poderá gerenciar vulnerabilidades antes que ocorram danos significativos.
Para atingir esse objetivo, as equipes devem começar com algumas práticas importantes, ter conversas frequentes sobre como melhorar e repetir e adotar gradualmente práticas de segurança adicionais.
Conclusão
Até recentemente, a segurança costumava ser tratada como uma reflexão tardia no ciclo de vida de desenvolvimento de software. No entanto, devido a importantes violações recentes de segurança, as equipes estão investindo esforços na alteração do status quo, para incorporar práticas de segurança no processo de atualização de um produto ou sistema.
As metodologias ágeis forneceram às equipes um excelente processo para incorporar práticas continuamente em todas as etapas do ciclo de vida do desenvolvimento. Recomendamos abordar as práticas de segurança de maneira semelhante, desenvolvendo uma forte cultura e práticas padrão ao longo do ciclo de vida do desenvolvimento. Mas, como na transformação ou adoção, esse processo pode ser longo e difícil e não existe uma fórmula secreta. Como resultado, é vital que todas as equipes tomem medidas em direção à segurança agora, introduzam práticas onde façam mais sentido, avaliem os resultados dessas mudanças, aprendam com elas, se adaptem – e depois repitam.
FONTE: https://www.thoughtworks.com/insights/blog/incorporating-security-best-practices-agile-teams