Independentemente do tipo de modelo de processo de desenvolvimento software (tradicional ou ágil) adotado por um projeto, as etapas do ciclo de desenvolvimento tipicamente são as mesmas:
A mitigação de problemas de segurança é menos onerosa quando realizada durante os estágios iniciais do ciclo de vida de um projeto. A detecção tardia de problemas acarreta em custos adicionais de replanejamento para a adequação, além de aumentar o risco de ataques bem-sucedidos contra o produto, caso ele já tenha sido publicado. Quando as validações de segurança são feitas apenas após o final do desenvolvimento, a responsabilidade pelas decisões é delegada aos desenvolvedores, que precisam “adivinhar” as reais necessidades do projeto e saber atendê-las, ocasionando ainda mais pressão para a entrega do produto dentro do prazo acordado, tornando a consideração dos aspectos de segurança algo não prioritário.
Frequentemente, as escolhas para a correção adequada dos defeitos de segurança encontrados durante os testes ou mesmo durante a operação dos sistemas em produção ficam a cargo dos desenvolvedores. Essa separação cria atrito entre os times de desenvolvimento e de segurança. Similar a outras disciplinas relacionadas aos produtos de software, segurança é uma área de conhecimento especializada e complexa. Suas atribuições não deveriam ser de responsabilidade apenas dos desenvolvedores. Existe uma maneira melhor de tratar a segurança de modo a reduzir riscos e custos: aproximar o time de segurança dos times de desenvolvimento e de operações, para que trabalhem juntos durante todas as fases do ciclo de desenvolvimento, integrando as melhores práticas ao processo, validando as escolhas e resultados de cada etapa.
Afinal, O que é AppSec?
O conceito de AppSec (Application Security) consiste na aplicação das melhores práticas de segurança ao longo de todas as etapas do ciclo de desenvolvimento de software visando a identificação, correção e a prevenção de problemas de segurança no produto. Dessa forma, as considerações de segurança são deliberadas durante as etapas iniciais do processo, e não apenas ao final do desenvolvimento. Esse deslocamento para contemplar todas as fases é chamado de shift-left-security.
Não existe uma solução única que atenda a todos os times e produtos. As medidas adotadas precisam ser ajustadas para melhor atender as peculiaridades de cada empresa, da maturidade de seus processos, do fluxo de trabalho ideal para cada time e do tipo de software desenvolvido. Embora o processo seja diferente para cada organização, algumas práticas de AppSec são comuns e podem ser adaptadas a qualquer processo. Existem guias especializados que fornecem orientações para auxiliar na criação de fluxos de trabalho seguros. Um desses guias é fornecido pela Microsoft, que foi uma das pioneiras na adoção das práticas de segurança ao longo do processo de desenvolvimento. > https://www.microsoft.com/en-us/securityengineering/sdl/practices
Outros guias podem ser encontrados no site da OWASP. > https://owasp.org/Top10/A00_2021-How_to_start_an_AppSec_program_with_the_OWASP_Top_10/
https://owasp.org/www-project-appsec-pipeline/
AppSec: Tornando o processo de desenvolvimento seguro
Para cada fase do ciclo de desenvolvimento, é possível adotar práticas que melhoram a postura de segurança dos times e dos resultados obtidos. Vamos analisa-las individualmente abaixo:
Etapa 1: requisitos
A primeira etapa do ciclo de desenvolvimento é o ponto ideal para a definição de um sistema seguro. Os aspectos de privacidade, integridade, disponibilidade, monitoramento e outros pontos relacionados à operação devem ser planejados junto com os demais requisitos funcionais e não funcionais da aplicação. Isso reduz os riscos e diminui os custos com interrupções e replanejamentos para realizar adequações durante o desenvolvimento. Os níveis mínimos de garantias de segurança necessários para a aceitação do projeto devem ser definidos ainda nessa etapa, sempre considerando o grau de risco aceito pela organização nas decisões. Também é recomendável detalhar o fluxo de atividades e as verificações que deverão ser executadas pelos times durante o desenvolvimento e antes da revisão final de segurança.
Etapa 2: projeto
Uma vez definidos os requisitos, é necessário detalhar como as soluções escolhidas serão implementadas e validar as escolhas feitas. Detalhes de como os dados serão processados, protegidos e armazenados, controles de acesso e auditoria devem ser rigorosamente descritos e avaliados. É primordial o uso de padrões arquiteturais de segurança consolidados e que atendam aos princípios de proteção em camadas, separação de responsabilidades, privilégios mínimos e de redução da superfície de ataque.
O processo de modelagem de ameaças pode ajudar no mapeamento das ameaças que os componentes do sistema estão expostos e, também, na escolha dos controles de segurança que serão adotados para mitigar os riscos detectados. Essa é uma atividade que envolve todo o time e permite que as escolhas feitas durante as discussões sejam documentadas de maneira estruturada para referência posterior.
Etapa 3: desenvolvimento
Durante o desenvolvimento, é importante que sejam utilizados padrões de codificação seguros adequados para a linguagem de programação utilizada e ao ambiente operacional da aplicação. O uso de ferramentas automatizadas ajuda a manter a qualidade e a consistência do código-fonte, bem como a detecção de defeitos comuns de segurança. O uso de ferramentas de análise estática de código (SAST) durante o desenvolvimento também permite a automação das verificações de código, tornando as revisões mais ágeis e dando mais autonomia para os desenvolvedores. Entretanto, tais ferramentas possuem limitações e seu uso não é capaz de eliminar totalmente a necessidade de validações manuais ou revisão humana feita por especialistas em segurança.
Os componentes externos utilizados no desenvolvimento do software, tais como bibliotecas e serviços de terceiros devem ser frequentemente monitorados e atualizados caso tenham defeitos de segurança conhecidos.
Etapa 4: testes
Após a conclusão de uma etapa de desenvolvimento é necessário validar se os controles de segurança propostos foram realmente implantados e funcionam corretamente. Características como a integridade da memória, comunicação segura, privilégios de usuários, perfis de acesso, uso de recursos e outros comportamentos dinâmicos da aplicação devem ser monitorados. Ferramentas do tipo DAST podem ser utilizadas para ajudar na detecção de anomalias e defeitos no comportamento do software. Técnicas de fuzzing também podem ser aplicadas para induzir falhas no programa e revelar problemas.
Outra atividade que pode ser aplicada é o teste de penetração. Nesse tipo de teste, um profissional de segurança simula a ação de atacantes maliciosos com o objetivo de violar as garantias de segurança do sistema e causar comportamento anômalo. Ao final dos testes, é gerado um relatório com os defeitos de segurança encontrados, uma descrição de como explorá-los e orientações de como corrigi-los. Após a correção dos defeitos encontrados, é aconselhável incluir testes automatizados específicos a fim de evitar que modificações futuras do código causem regressões de segurança.
Etapa 5: produção
Ao publicar um software, é importante ter planos de ação bem definidos para detectar violações de segurança e agir corretamente caso um incidente de segurança ocorra. Os controles de segurança e os requisitos do time de operações para a instalação, monitoramento e auditoria devem ter sido validados completamente antes da publicação. Modificações do código-fonte ou de configurações do produto devem ser controladas e devidamente documentadas antes da liberação de novas versões. Dependendo do tipo de modificação, as verificações do ciclo de desenvolvimento devem ser feitas novamente.
Amadurecendo o processo de AppSec
Existem dois pilares fundamentais para a construção de um processo eficiente para o desenvolvimento seguro de software: educação e automação.
Difundir o conhecimento de segurança dentro dos times, garantindo que os envolvidos entendam a perspectiva de um atacante malicioso, motivações e as técnicas comumente utilizadas nos ataques ajudam a chamar a atenção para os problemas de segurança e faz com que o time considere questões de segurança ao longo de todo o processo. Não se trata de educar apenas os desenvolvedores; todos os envolvidos devem ter conhecimentos básicos de segurança e devem ser capazes de identificar problemas e de aplicar as melhores práticas, desde a concepção do negócio até a entrega do software para o usuário final.
Embora nem toda tarefa possa ser automatizada, algumas atividades de verificação de segurança podem ser integradas aos fluxos de trabalho para dar mais agilidade e autonomia aos times de desenvolvimento. É o caso das ferramentas de análise estática de código (SAST) e dos testes dinâmicos de segurança (DAST) em funcionalidades específicas. Com a automação, os times podem realizar testes de segurança sob demanda, sem depender do time de segurança e sem precisar aguardar o final do ciclo de desenvolvimento para validar o produto. Os especialistas em segurança passam a atuar na triagem dos defeitos detectados e na proposta de correção dos problemas encontrados. A análise manual de código e de comportamento dinâmico passa a ser aplicada apenas em casos específicos para funcionalidades novas ou de alto risco, ou mesmo quando o processo organizacional exigir.
Esse artigo apenas introduziu os conceitos de AppSec e como algumas atividades podem ser aplicadas no processo de desenvolvimento de software, a fim de torná-lo mais eficaz do ponto de vista de segurança, prevenindo vulnerabilidades no produto final e tornando-o mais seguro. Essas práticas também reduzem os riscos e os elevados custos de replanejamento para a correção tardia de defeitos de segurança nos projetos. Caso queira aprender mais sobre as práticas de AppSec e desenvolvimento seguro, os guias citados no artigo são ótimas referências e fornecem mais detalhes das atividades aplicáveis a cada etapa do processo, além de modelos para avaliar o grau de maturidade das práticas em uma organização.