Mobile Application Security Testing¶

Nas seções a seguir, forneceremos uma breve visão geral dos princípios gerais de teste de segurança e terminologia-chave. Os conceitos apresentados são em grande parte idênticos aos encontrados em outros tipos de penetration testing, portanto, se você é um testador experiente, pode estar familiarizado com parte do conteúdo.

Ao longo do guia, usamos "teste de segurança de aplicativos móveis" como uma expressão abrangente para se referir à avaliação da segurança de aplicativos móveis por meio de análise estática e dinâmica. Termos como "teste de penetração de aplicativos móveis" e "revisão de segurança de aplicativos móveis" são usados de forma um tanto inconsistente na indústria de segurança, mas esses termos se referem basicamente à mesma coisa. Um teste de segurança de aplicativo móvel geralmente faz parte de uma avaliação de segurança maior ou de um teste de penetração que abrange a arquitetura cliente-servidor e as APIs do lado do servidor usadas pelo aplicativo móvel.

Neste guia, abordamos o teste de segurança de aplicativos móveis em dois contextos. O primeiro é o teste de segurança "clássico" realizado próximo ao final do ciclo de vida de desenvolvimento. Nesse contexto, o testador acessa uma versão quase finalizada ou pronta para produção do aplicativo, identifica problemas de segurança e escreve um relatório (geralmente devastador). O outro contexto é caracterizado pela implementação de requisitos e pela automação de testes de segurança desde o início do ciclo de vida de desenvolvimento de software em diante. Os mesmos requisitos básicos e casos de teste se aplicam a ambos os contextos, mas o método de alto nível e o nível de interação com o cliente diferem.

Princípios de Teste¶

White-box Testing versus Black-box Testing¶

Vamos começar definindo os conceitos:

Black-box testing é conduzido sem que o testador tenha qualquer informação sobre o aplicativo sendo testado. Este processo é às vezes chamado de "zero-knowledge testing". O principal propósito deste teste é permitir que o testador se comporte como um atacante real no sentido de explorar usos possíveis para informações publicamente disponíveis e descobríveis.
White-box testing (às vezes chamado de "full knowledge testing") é o oposto completo do black-box testing no sentido de que o testador tem conhecimento total do aplicativo. O conhecimento pode abranger source code, documentação e diagramas. Esta abordagem permite um teste muito mais rápido do que o black-box testing devido à sua transparência e, com o conhecimento adicional obtido, um testador pode construir casos de teste muito mais sofisticados e granulares.
Gray-box testing é todo teste que se situa entre os dois tipos de teste mencionados anteriormente: alguma informação é fornecida ao testador (normalmente apenas credenciais), e outras informações devem ser descobertas. Este tipo de teste é um compromisso interessante no número de casos de teste, no custo, na velocidade e no escopo do teste. O gray-box testing é o tipo mais comum de teste na indústria de segurança.

Recomendamos fortemente que você solicite o source code para que possa utilizar o tempo de teste da forma mais eficiente possível. O acesso do testador ao código obviamente não simula um ataque externo, mas simplifica a identificação de vulnerabilidades ao permitir que o testador verifique cada anomalia identificada ou comportamento suspeito no nível do código. Um white-box test é o caminho a seguir se o aplicativo não foi testado anteriormente.

Embora a descompilação no Android seja direta, o source code pode estar ofuscado, e a desofuscação será demorada. Restrições de tempo são, portanto, outra razão para o testador ter acesso ao source code.

Vulnerability Analysis¶

Vulnerability analysis é geralmente o processo de buscar vulnerabilidades em um aplicativo. Embora isso possa ser feito manualmente, scanners automatizados são normalmente utilizados para identificar as principais vulnerabilidades. Análise estática e análise dinâmica são tipos de vulnerability analysis.

Static versus Dynamic Analysis¶

O Static Application Security Testing (SAST) envolve examinar os componentes de um aplicativo sem executá-los, por meio da análise do source code de forma manual ou automática. A OWASP fornece informações sobre Static Code Analysis que podem ajudá-lo a entender técnicas, pontos fortes, fracos e limitações.

O Dynamic Application Security Testing (DAST) envolve examinar o aplicativo durante a execução. Esse tipo de análise pode ser manual ou automática. Geralmente, não fornece as informações que a análise estática oferece, mas é uma boa maneira de detectar elementos interessantes (ativos, funcionalidades, pontos de entrada, etc.) do ponto de vista do usuário.

Agora que definimos análise estática e dinâmica, vamos nos aprofundar.

Static Analysis¶

Durante a análise estática, o source code do aplicativo móvel é revisado para garantir a implementação adequada dos controles de segurança. Na maioria dos casos, é utilizada uma abordagem híbrida automática/manual. As varreduras automáticas identificam as vulnerabilidades mais evidentes, e o testador humano pode explorar a base de código com contextos de uso específicos em mente.

Manual Code Review¶

Um testador realiza o manual code review analisando manualmente o source code do aplicativo móvel em busca de vulnerabilidades de segurança. Os métodos variam desde uma busca básica por palavras-chave através do comando 'grep' até um exame linha por linha do source code. As IDEs (Ambientes de Desenvolvimento Integrados) frequentemente fornecem funções básicas de revisão de código e podem ser estendidas com várias ferramentas.

Uma abordagem comum para análise manual de código envolve a identificação de indicadores-chave de vulnerabilidades de segurança através da busca por determinadas APIs e palavras-chave, como chamadas de métodos relacionados a banco de dados como "executeStatement" ou "executeQuery". Códigos contendo essas strings são um bom ponto de partida para análise manual.

Em contraste com a análise automática de código, a revisão manual é muito eficaz para identificar vulnerabilidades na business logic, violações de padrões e falhas de design, especialmente quando o código é tecnicamente seguro mas logicamente falho. Tais cenários dificilmente seriam detectados por qualquer ferramenta de análise automática de código.

Uma revisão manual de código requer um revisor especialista que seja proficiente tanto na linguagem quanto nos frameworks utilizados para o aplicativo móvel. A revisão completa de código pode ser um processo lento, tedioso e demorado para o revisor, especialmente considerando bases de código grandes com muitas dependências.

Automated Source Code Analysis¶

Ferramentas de análise automatizada podem ser usadas para acelerar o processo de revisão do Static Application Security Testing (SAST). Elas verificam o source code quanto à conformidade com um conjunto predefinido de regras ou melhores práticas do setor, normalmente exibindo uma lista de achados, alertas e sinalizações para todas as violações detectadas. Algumas ferramentas de análise estática executam apenas contra o aplicativo compilado, outras precisam receber o source code original, e algumas funcionam como plugins de análise em tempo real no Integrated Development Environment (IDE).

Embora algumas ferramentas de análise estática de código incorporem muitas informações sobre as regras e semântica necessárias para analisar aplicativos móveis, elas podem produzir muitos false positives, especialmente se não estiverem configuradas para o ambiente de destino. Portanto, um profissional de segurança deve sempre revisar os resultados.

Dynamic Analysis¶

O foco do DAST é o teste e a avaliação de aplicativos por meio de sua execução em tempo real. O principal objetivo da análise dinâmica é encontrar vulnerabilidades de segurança ou pontos fracos em um programa enquanto ele está em execução. A análise dinâmica é conduzida tanto na camada da plataforma móvel quanto contra os serviços e APIs backend, onde os padrões de solicitação e resposta do aplicativo móvel podem ser analisados.

A análise dinâmica é geralmente utilizada para verificar se os mecanismos de segurança fornecem proteção suficiente contra os tipos mais comuns de ataque, como a divulgação de dados em trânsito, problemas de autenticação e autorização, e erros de configuração do servidor.

Evitando False Positives¶

Automated Scanning Tools¶

A falta de sensibilidade das ferramentas de teste automatizado ao contexto do aplicativo é um desafio. Essas ferramentas podem identificar um problema potencial que é irrelevante. Tais resultados são chamados de "false positives".

Por exemplo, testadores de segurança frequentemente relatam vulnerabilidades que são exploráveis em um navegador web, mas não são relevantes para o aplicativo móvel. Este false positive ocorre porque as ferramentas automatizadas usadas para escanear o serviço backend são baseadas em aplicações web regulares para navegadores. Problemas como CSRF (Cross-Site Request Forgery) e Cross-Site Scripting (XSS) são relatados de acordo.

Vamos tomar o CSRF como exemplo. Um ataque CSRF bem-sucedido requer o seguinte:

A capacidade de induzir o usuário logado a abrir um link malicioso no navegador web usado para acessar o site vulnerável.
O cliente (navegador) deve adicionar automaticamente o cookie de sessão ou outro token de autenticação à requisição.

Aplicativos móveis não atendem a esses requisitos: mesmo que WebViews e gerenciamento de sessão baseado em cookie sejam usados, qualquer link malicioso que o usuário clicar será aberto no navegador padrão, que possui um armazenamento de cookies separado.

Cross-Site Scripting (XSS) armazenado pode ser um problema se o aplicativo incluir WebViews, e pode até levar à execução de comandos se o aplicativo exportar interfaces JavaScript. No entanto, Cross-Site Scripting refletido raramente é um problema pelo motivo mencionado acima (embora seja discutível se eles deveriam existir, escapar a saída é simplesmente uma prática recomendada).

Em qualquer caso, considere cenários de exploração quando realizar a avaliação de risco; não confie cegamente na saída da sua ferramenta de varredura.

Penetration Testing (a.k.a. Pentesting)¶

A abordagem clássica envolve testes de segurança abrangentes da versão final ou quase final do aplicativo, por exemplo, a versão disponível ao final do processo de desenvolvimento. Para testes realizados no final do processo de desenvolvimento, recomendamos o Mobile App Security Verification Standard (MASVS) e a lista de verificação associada como linha de base para os testes. Um teste de segurança típico é estruturado da seguinte forma:

Preparation - definição do escopo do teste de segurança, incluindo a identificação dos controles de segurança aplicáveis, os objetivos de teste da organização e os dados sensíveis. De forma mais ampla, a preparação inclui toda a sincronização com o cliente, bem como a proteção legal do testador (que frequentemente é um terceiro). Lembre-se: atacar um sistema sem autorização por escrito é ilegal em muitas partes do mundo!
Intelligence Gathering - análise do contexto ambiental e arquitetônico do aplicativo para obter uma compreensão contextual geral.
Mapping the Application - com base nas informações das fases anteriores; pode ser complementado por varredura automatizada e exploração manual do aplicativo. O mapeamento fornece uma compreensão detalhada do aplicativo, seus pontos de entrada, os dados que ele mantém e as principais vulnerabilidades potenciais. Essas vulnerabilidades podem então ser classificadas de acordo com o dano que sua exploração causaria, para que o testador de segurança possa priorizá-las. Esta fase inclui a criação de test cases que podem ser utilizados durante a execução do teste.
Exploitation - nesta fase, o testador de segurança tenta penetrar no aplicativo explorando as vulnerabilidades identificadas durante a fase anterior. Esta fase é necessária para determinar se as vulnerabilidades são reais e verdadeiros positivos.
Reporting - nesta fase, que é essencial para o cliente, o testador de segurança reporta as vulnerabilidades. Isso inclui o processo de exploração em detalhes, classifica o tipo de vulnerabilidade, documenta o risco se um invasor conseguir comprometer o alvo e descreve quais dados o testador conseguiu acessar ilegitimamente.

Preparation¶

Antes de iniciar os testes, é necessário definir o nível de segurança em que o aplicativo será testado. Os requisitos de segurança devem ser estabelecidos no início do projeto. Diferentes organizações possuem necessidades de segurança distintas e recursos variados disponíveis para investir em atividades de teste. Embora os testes do perfil MAS-L1 sejam aplicáveis a todos os aplicativos móveis, percorrer todos os testes do MAS-L1 e MAS-L2 com as partes interessadas técnicas e de negócios é uma boa maneira de definir um nível de cobertura de teste.

As organizações podem ter obrigações regulatórias e legais diferentes em determinados territórios. Mesmo que um aplicativo não lide com dados sensíveis, alguns testes do MAS-L2 podem ser relevantes (devido a regulamentações do setor ou leis locais). Por exemplo, a two-factor authentication (2FA) pode ser obrigatória para um aplicativo financeiro e imposta pelo banco central de um país e/ou autoridades reguladoras financeiras.

Os objetivos/controles de segurança definidos anteriormente no processo de desenvolvimento também podem ser revisados durante a discussão com as partes interessadas. Alguns controles podem estar em conformidade com os perfis MAS, mas outros podem ser específicos da organização ou do aplicativo.

Todas as partes envolvidas devem concordar com as decisões e o escopo definidos na checklist, pois estes estabelecerão a base de referência para todos os testes de segurança.

Coordinating with the Client¶

Configurar um ambiente de teste funcional pode ser uma tarefa desafiadora. Por exemplo, restrições nos pontos de acesso sem fio corporativos e nas redes podem impedir a análise dinâmica realizada nas instalações do cliente. Políticas da empresa podem proibir o uso de rooted phones ou ferramentas de teste de rede (de hardware e software) dentro das redes corporativas. Aplicativos que implementam detecção de root e outras contramedidas de engenharia reversa podem aumentar significativamente o trabalho necessário para análises posteriores.

O teste de segurança envolve muitas tarefas invasivas, incluindo monitoramento e manipulação do tráfego de rede do aplicativo móvel, inspeção dos arquivos de dados do app e instrumentação de chamadas de APIs. Controles de segurança, como certificate pinning e detecção de root, podem impedir essas tarefas e reduzir drasticamente a velocidade dos testes.

Para superar esses obstáculos, você pode solicitar duas variantes de build do aplicativo à equipe de desenvolvimento. Uma variante deve ser uma release build para que você possa determinar se os controles implementados estão funcionando corretamente e não podem ser contornados facilmente. A segunda variante deve ser uma debug build para a qual certos controles de segurança foram desativados. Testar duas builds diferentes é a maneira mais eficiente de cobrir todos os test cases.

Dependendo do escopo do projeto, essa abordagem pode não ser possível. Solicitar tanto builds de produção quanto de debug para um white-box test ajudará você a concluir todos os test cases e declarar claramente a maturidade de segurança do aplicativo. O cliente pode preferir que black-box tests sejam focados no aplicativo de produção e na avaliação da eficácia de seus controles de segurança.

O escopo de ambos os tipos de teste deve ser discutido durante a fase de preparation. Por exemplo, se os controles de segurança devem ser ajustados deve ser decidido antes do teste. Tópicos adicionais são discutidos abaixo.

Identifying Sensitive Data¶

As classificações de informações sensíveis variam conforme o setor e o país. Além disso, as organizações podem adotar uma visão restritiva sobre dados sensíveis e podem ter uma política de classificação de dados que define claramente o que constitui informação sensível.

Existem três estados gerais a partir dos quais os dados podem ser acessíveis:

At rest - os dados estão armazenados em um arquivo ou repositório de dados
In use - um aplicativo carregou os dados em seu espaço de endereçamento
In transit - os dados foram trocados entre o aplicativo móvel e um endpoint ou processos consumidores no dispositivo, por exemplo, durante IPC (Comunicação Interprocessos)

O nível de escrutínio apropriado para cada estado pode depender da importância dos dados e da probabilidade de serem acessados. Por exemplo, dados mantidos na memória do aplicativo podem ser mais vulneráveis do que dados em servidores web a acessos via core dumps, pois é mais provável que atacantes obtenham acesso físico a dispositivos móveis do que a servidores web.

Quando não houver uma política de classificação de dados disponível, utilize a seguinte lista de informações geralmente consideradas sensíveis:

informações de autenticação do usuário (credenciais, PINs, etc.)
Personally Identifiable Information (PII) que podem ser usadas para roubo de identidade: números de previdência social, números de cartão de crédito, números de conta bancária, informações de saúde
identificadores de dispositivo que possam identificar uma pessoa
dados altamente sensíveis cujo comprometimento levaria a danos reputacionais e/ou custos financeiros
quaisquer dados cuja proteção seja uma obrigação legal
quaisquer dados técnicos gerados pelo aplicativo (ou seus sistemas relacionados) e usados para proteger outros dados ou o próprio sistema (por exemplo, chaves de criptografia)

Uma definição de "dados sensíveis" deve ser estabelecida antes do início dos testes, pois detectar vazamento de dados sensíveis sem uma definição pode ser impossível.

Identifying Security-Relevant Contexts in Code¶

Ao desenvolver um aplicativo móvel, é crucial identificar e tratar com precisão os contextos relevantes para segurança dentro da base de código. Esses contextos normalmente envolvem operações como autenticação, criptografia e autorização, que frequentemente são alvo de ataques de segurança. A implementação incorreta de funções criptográficas nessas áreas pode levar a vulnerabilidades de segurança significativas.

Distinguir adequadamente os contextos relevantes para segurança ajuda a minimizar false positives durante os testes de segurança. False positives podem desviar a atenção de problemas reais e desperdiçar recursos valiosos. Aqui estão alguns cenários comuns:

Random Number Generation: O uso de geradores de números aleatórios previsíveis pode ser uma falha de segurança grave em contextos como autenticação ou geração de chaves de criptografia. No entanto, nem todos os usos de números aleatórios são sensíveis à segurança. Por exemplo, usar um gerador de números aleatórios menos robusto para fins não relacionados à segurança, como embaralhar uma lista de itens em um jogo, geralmente é aceitável.
Hashing: O hashing é frequentemente usado na segurança para armazenar senhas ou garantir a integridade dos dados. No entanto, aplicar hash a um valor não sensível, como a resolução de tela de um dispositivo para análises, não é uma preocupação de segurança.
Encryption vs Encoding: Um equívoco comum é confundir codificação (como Base64) com criptografia. A codificação Base64 não é um método seguro para proteger dados sensíveis, pois é facilmente reversível. É crucial reconhecer quando os dados exigem criptografia real (para confidencialidade) versus quando estão sendo codificados por motivos de compatibilidade ou formatação (como codificar dados binários em formato de texto para transmissão). Interpretar erroneamente a codificação como uma medida de segurança pode levar a negligenciar as necessidades reais de criptografia para dados sensíveis.
API Token Storage: Armazenar tokens ou chaves de API em texto simples no código do aplicativo ou em locais inseguros (como SharedPreferences no Android ou UserDefaults no iOS) é um erro de segurança comum. No entanto, se o token for para uma API pública não sensível e somente leitura, isso pode não representar um risco de segurança. Contrastando com o armazenamento de um token para uma API sensível ou com acesso de escrita, onde o armazenamento inadequado seria uma preocupação de segurança significativa.

Intelligence Gathering¶

A intelligence gathering envolve a reunião de informações sobre a arquitetura do aplicativo, os casos de uso de negócio atendidos pelo aplicativo e o contexto no qual o aplicativo opera. Tais informações podem ser classificadas como "ambientais" ou "arquiteturais".

Environmental Information¶

As environmental information incluem:

Os objetivos da organização para o aplicativo. A funcionalidade molda a interação dos usuários com o aplicativo e pode tornar algumas superfícies mais propensas a serem alvo de atacantes do que outras.
O setor relevante. Diferentes setores podem ter perfis de risco distintos.
Partes interessadas e investidores; compreender quem está interessado e é responsável pelo aplicativo.
Processos internos, fluxos de trabalho e estruturas organizacionais. Processos e fluxos de trabalho internos específicos da organização podem criar oportunidades para business logic vulnerabilities.

Architectural Information¶

As architectural information incluem:

O aplicativo móvel: Como o aplicativo acessa dados e os gerencia em processo, como se comunica com outros recursos e gerencia sessões de usuário, e se detecta que está sendo executado em dispositivos jailbroken ou rooted e reage a essas situações.
O Sistema Operacional: Os sistemas operacionais e versões do SO em que o aplicativo é executado (incluindo restrições de versão do Android ou iOS), se espera-se que o aplicativo seja executado em dispositivos que possuem controles de Mobile Device Management (MDM) e vulnerabilidades relevantes do SO.
Rede: Uso de protocolos de transporte seguros (por exemplo, TLS), uso de chaves fortes e algoritmos criptográficos (por exemplo, SHA-2) para proteger a criptografia do tráfego de rede, uso de certificate pinning para verificar o endpoint, etc.
Serviços Remotos: Os serviços remotos que o aplicativo consome e se o comprometimento deles pode comprometer o cliente.

Mapping the Application¶

Uma vez que o testador de segurança possui informações sobre o aplicativo e seu contexto, o próximo passo é mapear a estrutura e o conteúdo do aplicativo, por exemplo, identificando seus pontos de entrada, funcionalidades e dados.

Quando o teste de penetração é realizado em um paradigma de white-box ou grey-box, quaisquer documentos do interior do projeto (diagramas de arquitetura, especificações funcionais, código, etc.) podem facilitar bastante o processo. Se o source code estiver disponível, o uso de ferramentas SAST pode revelar informações valiosas sobre vulnerabilidades (por exemplo, SQL Injection). Ferramentas DAST podem apoiar black-box testing e escanear automaticamente o aplicativo: enquanto um testador precisará de horas ou dias, um scanner pode realizar a mesma tarefa em alguns minutos. No entanto, é importante lembrar que as ferramentas automáticas têm limitações e encontrarão apenas o que foram programadas para encontrar. Portanto, a análise humana pode ser necessária para complementar os resultados das ferramentas automáticas (a intuição é frequentemente fundamental para testes de segurança).

A Threat Modeling é um artefato importante: documentos do workshop geralmente apoiam muito a identificação de grande parte das informações que um testador de segurança precisa (pontos de entrada, ativos, vulnerabilidades, severidade, etc.). É altamente recomendado que os testadores discutam a disponibilidade de tais documentos com o cliente. A threat modeling deve ser uma parte fundamental do ciclo de vida de desenvolvimento de software. Ela geralmente ocorre nas fases iniciais de um projeto.

As diretrizes de threat modeling definidas pela OWASP são geralmente aplicáveis a aplicativos móveis.

Exploitation¶

Infelizmente, restrições de tempo ou financeiras limitam muitos pentests ao mapeamento de aplicações por meio de scanners automatizados (para vulnerability analysis, por exemplo). Embora as vulnerabilidades identificadas durante a fase anterior possam ser interessantes, sua relevância deve ser confirmada em relação a cinco eixos:

Damage potential — o dano que pode resultar da exploração da vulnerabilidade
Reproducibility — facilidade de reproduzir o ataque
Exploitability — facilidade de executar o ataque
Affected users — o número de usuários afetados pelo ataque
Discoverability — facilidade de detectar a vulnerabilidade

Contra todas as expectativas, algumas vulnerabilidades podem não ser exploráveis e podem levar a comprometimentos menores, se houver. Outras vulnerabilidades podem parecer inofensivas à primeira vista, mas se mostrar muito perigosas sob condições realistas de teste. Testadores que percorrem cuidadosamente a fase de exploitation apoiam o pentest caracterizando as vulnerabilidades e seus efeitos.

Reporting¶

As descobertas do testador de segurança serão valiosas para o cliente apenas se estiverem claramente documentadas. Um bom relatório de pentest deve incluir informações como, mas não se limitando a:

um executive summary
uma descrição do escopo e contexto (por exemplo, sistemas direcionados)
métodos utilizados
fontes de informação (fornecidas pelo cliente ou descobertas durante o pentest)
descobertas priorizadas (por exemplo, vulnerabilidades estruturadas pela classificação DREAD)
descobertas detalhadas
recomendações para corrigir cada defeito

Muitos modelos de relatório de pentest estão disponíveis na Internet: o Google é seu amigo!

Security Testing and the SDLC¶

Embora os princípios do teste de segurança não tenham mudado fundamentalmente na história recente, as técnicas de desenvolvimento de software mudaram drasticamente. Enquanto a adoção generalizada de práticas ágeis acelerava o desenvolvimento de software, os testadores de segurança tiveram que se tornar mais rápidos e ágeis, continuando a entregar software confiável.

A seção a seguir está focada nessa evolução e descreve o teste de segurança contemporâneo.

Security Testing during the Software Development Life Cycle¶

O desenvolvimento de software não é muito antigo, afinal de contas, então é fácil observar o fim do desenvolvimento sem uma estrutura. Todos nós já experimentamos a necessidade de um conjunto mínimo de regras para controlar o trabalho à medida que o source code cresce.

No passado, as metodologias "Waterfall" eram as mais adotadas: o desenvolvimento prosseguia por etapas que tinham uma sequência predefinida. Limitada a uma única etapa, a capacidade de retrocesso era uma desvantagem séria das metodologias Waterfall. Embora tenham características positivas importantes (fornecer estrutura, ajudar os testadores a esclarecer onde o esforço é necessário, serem claras e fáceis de entender, etc.), também têm negativas (criar silos, serem lentas, equipes especializadas, etc.).

À medida que o desenvolvimento de software amadureceu, a competição aumentou e os desenvolvedores precisaram reagir às mudanças do mercado mais rapidamente, enquanto criavam produtos de software com orçamentos menores. A ideia de menos estrutura tornou-se popular, e equipes menores colaboraram, quebrando silos em toda a organização. O conceito "Agile" nasceu (Scrum, XP e RAD são exemplos bem conhecidos de implementações Ágeis); ele permitiu que equipes mais autônomas trabalhassem juntas mais rapidamente.

A segurança originalmente não era uma parte integral do desenvolvimento de software. Era uma reflexão tardia, realizada no nível de rede por equipes de operação que tinham que compensar a segurança deficiente do software! Embora a segurança não integrada fosse possível quando os programas de software estavam localizados dentro de um perímetro, o conceito tornou-se obsoleto à medida que novos tipos de consumo de software surgiram com tecnologias web, móveis e IoT. Atualmente, a segurança deve ser incorporada dentro do software, porque compensar vulnerabilidades geralmente é muito difícil.

"SDLC" será usado alternadamente com "Secure SDLC" na seção a seguir para ajudá-lo a internalizar a ideia de que a segurança é parte dos processos de desenvolvimento de software. No mesmo espírito, usamos o nome DevSecOps para enfatizar o fato de que a segurança é parte do DevOps.

SDLC Overview¶

General Description of SDLC¶

Os SDLCs sempre consistem nas mesmas etapas (o processo geral é sequencial no paradigma Waterfall e iterativo no paradigma Agile):

Realize uma risk assessment para o aplicativo e seus componentes para identificar seus perfis de risco. Esses perfis de risco normalmente dependem do apetite de risco da organização e dos requisitos regulatórios aplicáveis. A risk assessment também é baseada em fatores, incluindo se o aplicativo é acessível via Internet e o tipo de dados que o aplicativo processa e armazena. Todos os tipos de riscos devem ser considerados: financeiros, de marketing, industriais, etc. Políticas de classificação de dados especificam quais dados são sensíveis e como devem ser protegidos.
Security Requirements são determinados no início de um projeto ou ciclo de desenvolvimento, quando os requisitos funcionais estão sendo coletados. Abuse Cases são adicionados à medida que os casos de uso são criados. As equipes (incluindo equipes de desenvolvimento) podem receber treinamento em segurança (como Secure Coding) se necessário. Você pode usar o OWASP MASVS e o OWASP MASWE para determinar os requisitos de segurança de aplicativos móveis com base na fase de risk assessment. A revisão iterativa dos requisitos quando recursos e classes de dados são adicionados é comum, especialmente em projetos Agile.
Threat Modeling, que basicamente é a identificação, enumeração, priorização e tratamento inicial de ameaças, é um artefato fundamental que deve ser realizado à medida que a arquitetura e o design evoluem. A Security Architecture, um fator da Threat Model, pode ser refinada (tanto para aspectos de software quanto de hardware) após a fase de Threat Modeling. Regras de Secure Coding são estabelecidas e a lista de Security tools que serão usadas é criada. A estratégia para Security testing é esclarecida.
Todos os requisitos de segurança e considerações de design devem ser armazenados no Application Life Cycle Management (ALM) system (também conhecido como rastreador de problemas) que a equipe de desenvolvimento/operações usa para garantir a integração estreita dos requisitos de segurança no fluxo de trabalho de desenvolvimento. Os requisitos de segurança devem conter trechos de source code relevantes para que os desenvolvedores possam consultá-los rapidamente. Criar um repositório dedicado que esteja sob controle de versão e contenha apenas esses trechos de código é uma estratégia de codificação segura mais benéfica do que a abordagem tradicional (armazenar as diretrizes em documentos Word ou PDFs).
Desenvolva o software com segurança. Para aumentar a segurança do código, você deve completar atividades como Security Code Reviews, Static Application Security Testing, e Security Unit Testing. Embora existam análogos de qualidade dessas atividades de segurança, a mesma lógica deve ser aplicada à segurança, por exemplo, revisar, analisar e testar o código em busca de defeitos de segurança (como validação de entrada ausente, falha em liberar todos os recursos, etc.).
Em seguida, vem o tão aguardado teste do candidato a lançamento: Penetration Testing ("Pentests") manual e automatizado. O Dynamic Application Security Testing geralmente também é realizado durante esta fase.
Após o software ser Accredited durante Acceptance por todas as partes interessadas, ele pode ser transferido com segurança para as equipes de Operation e colocado em Produção.
A última fase, muitas vezes negligenciada, é a Decommissioning segura do software após o fim de seu uso.

A imagem abaixo ilustra todas as fases e artefatos:

SDLC Overview

Com base no perfil de risco geral do projeto, você pode simplificar (ou até pular) alguns artefatos e pode adicionar outros (aprovações intermediárias formais, documentação formal de certos pontos, etc.). Lembre-se sempre de duas coisas: um SDLC tem como objetivo reduzir os riscos associados ao desenvolvimento de software e é uma estrutura que ajuda você a estabelecer controles para esse fim. Esta é uma descrição genérica do SDLC; sempre adapte essa estrutura aos seus projetos.

Defining a Test Strategy¶

Test strategies especificam os testes que serão realizados durante o SDLC, bem como a frequência dos testes. As test strategies são utilizadas para garantir que o produto de software final atenda aos objetivos de segurança, que geralmente são determinados pelas equipes jurídicas/marketing/corporativas dos clientes. A test strategy normalmente é criada durante a fase de Secure Design, após os riscos terem sido esclarecidos (durante a fase de Initiation) e antes do início do desenvolvimento de código (fase de Secure Implementation). A estratégia requer contribuições de atividades como Risk Management, Threat Modeling anterior e Security Engineering.

Uma Test Strategy não precisa ser formalmente documentada: pode ser descrita por meio de Histórias (em projetos Agile), rapidamente enumerada em checklists ou especificada como test cases para uma determinada ferramenta. No entanto, a estratégia definitivamente deve ser compartilhada, pois precisa ser implementada por uma equipe diferente daquela que a definiu. Além disso, todas as equipes técnicas devem concordar com ela para garantir que não imponha cargas inaceitáveis a nenhuma delas.

Test Strategies abordam tópicos como:

objetivos e descrições de riscos
planos para atingir objetivos, redu