As revisões de diagramas de design por especialistas podem detectar possíveis brechas de segurança que não foram encontradas nas varreduras de vulnerabilidades ou pela automação de segurança. Essas análises devem focar em funções críticas como emissão e gerenciamento de tokens de acesso, transferência de dados para serviços externos e execução de código não confiável, disse Kevin Gilpin, engenheiro de software corporativo e co-fundador da AppLand, na QCon London 2019.
Estamos acostumados a ver violações de segurança causadas por falhas técnicas, como acesso a memória insegura e vulnerabilidades OWASP. Porém ultimamente, ficamos sabendo de falhas graves que foram causadas por problemas fundamentais no projeto de software ou no aplicativo. Essas brechas não foram detectadas por varreduras de vulnerabilidades ou por outras formas de automação de segurança, disse Gilpin. Um exemplo é o Facebook que neste ano teve que redefinir os tokens de acesso de segurança de 50 milhões de usuários depois que um de seus novos recursos, o Visualizar Como, foi encontrado uma falha de segurança que estava vazando tokens de acesso para usuários não autorizados.
As falhas de segurança no design de aplicativos podem ter um enorme impacto, disse Gilpin. Frequentemente, não há como mitigar essas falhas sem ter que voltar ao planejamento inicial e reescrever completamente o software. Muitas organizações regulamentadas e certificadas (como a ISO e a HIPAA) têm uma revisão de projeto de várias etapas, o que pode ajudar a encontrar falhas de segurança. O truque é adaptar esse processo ao desenvolvimento de fluxo rápido.
O primeiro passo é verificar nos projetos ou componentes onde está o maior risco. Normalmente essas áreas são as que executam as funções mais críticas. Gilpin comentou alguns exemplos como, emissão e gerenciamento de tokens de acesso, transferência de dados para serviços externos e execução de código não confiável. Estes são algumas das áreas funcionais que, se projetadas de maneira incorreta, podem levar a críticas violações de segurança.
Quando essas áreas de alto risco do código são identificadas, um conjunto de diagramas precisos de projeto é preparado pela equipe de engenharia. Idealmente, os diagramas são gerados diretamente do código usando ferramentas de automação, disse Gilpin. Se necessário, podem ser complementadas com diagramas desenhados a mão, embora seja mais difícil mantê-los atualizados se a base de código é constantemente alterada. Depois de preparados, os diagramas são distribuídos juntamente com algum texto explicativo para revisão por especialistas. Gilpin sugeriu que cada revisor se concentraria em verificar o design de um ponto de vista específico. Mais importante ainda, um revisor deve identificar quando um projeto existente e conhecido, como um RFC, pode ser usado no lugar de um design interno personalizado.
O revisor de segurança deve estar familiarizado com as melhores práticas e o estado da arte em relação à autenticação, autorização, OWASP e manipulação segura de código não confiável e entrada de usuário não confiável, disse Gilpin. Se não houver mão de obra com este tipo de conhecimento dentro da organização, uma boa ideia pode ser ampliar a pesquisa ou talvez, contratar um especialista externo para realizar esta análise. Podemos dizer que será um dinheiro bem gasto, quando comparado ao dano monetário e de reputação que uma violação pode causar.
O InfoQ cobriu o QCon London 2019 e conversou com Kevin Gilpin sobre o papel dos artefatos de arquitetura e design quando se trata de segurança.
InfoQ: Quais são as propriedades da arquitetura cognitiva ou artefatos de design?
Kevin Gilpin: Um bom artefato cognitivo, como um diagrama de arquitetura ou diagrama de design de software, deve ser algo que possa ajudar a concentrar a atenção das pessoas que precisam pensar sobre o assunto. Se essas pessoas não estão envolvidas no desenvolvimento, os diagramas devem ser fáceis para não-desenvolvedores para entenderem também. No entanto, um bom artefato cognitivo também deve representar o design e o comportamento real do software o suficiente para fornecer uma visão precisa de como o sistema funciona.
Este é um problema de Goldilocks que dependente do seu público. Se houver muitos detalhes do código, os não programadores talvez não conseguirão entendê-lo. E se for muito alto nível para representar as complexidades do design, os diagramas não serão úteis como uma maneira de obter feedback e sugestões.
InfoQ: O que pode ser feito para garantir que os artefatos de arquitetura e design estejam atualizados?
Gilpin: Este é um problema difícil. Temos um histórico de esforços como o CASE (computer aided software engineering), que tentou colocar diagramas de projeto no centro do processo de engenharia de software. No entanto, no mundo de hoje, o código é o rei. O código está no centro de processos críticos, como revisões de código, solicitações de pull e merge, testes automatizados, integração contínua e implantação automatizada. Assim, os artefatos de design só permanecem atualizados se houver esforço para mantê-los atualizados com o código em constante alteração. É por isso que os artefatos de design estão normalmente desatualizados e, portanto, não estão atualmente no centro de nenhum processo importante no desenvolvimento de software. Existem algumas ferramentas automatizadas que podem ajudar a fornecer insights de design diretamente do código, mas são limitadas. Esta é uma área em que precisamos de inovação em técnicas, práticas e ferramentas.
InfoQ: O que pode ser feito para acomodar as necessidades de interessados técnicos e não técnicos ao discutir segurança?
Gilpin: Para detectar falhas como a violação do Visualizar Como do Facebook, é importante que um círculo mais amplo de pessoas seja capaz de entender e pensar sobre o design de aplicativos de software. Desenvolvedores de software têm muitas responsabilidades; desenvolver, codificar, testar, fazer as integrações contínuas, DevOps, estimar, verificar desempenho, corrigir bugs, aprender de novas tecnologias, melhorar a comunicação entre eles, etc. Às vezes, as preocupações de segurança podem ficar para trás. As equipes de segurança, por outro lado, podem se concentrar na segurança. Portanto, se os desenvolvedores puderem tornar seus designs acessíveis à segurança, e se os desenvolvedores e as equipes de segurança puderem trabalhar juntos de maneira produtiva na organização, poderão então ser uma ferramenta poderosa para melhorar a segurança dos aplicativos.