Segurança de aplicativos ou Como incorporar segurança no desenvolvimento personalizado. Experiência pessoal na AGIMA

As agências digitais estão prestando cada vez mais atenção à segurança da infraestrutura em que estão desenvolvendo e também estão começando a procurar garantir a segurança dos aplicativos. Você provavelmente leu sobre a variedade e criticidade de vulnerabilidades, ferramentas e métodos para fornecer segurança da informação. Mas como ignorar ou garantir a segurança do aplicativo afeta o próprio processo de desenvolvimento personalizado?

Conteúdo do artigo:

Não repetiremos pela centésima vez por que a segurança é tão importante, quais vulnerabilidades existem ou como a equipe vermelha derrota a equipe azul na próxima batalha. Esta é uma breve história sobre por que adicionamos segurança ao desenvolvimento personalizado e como o fizemos.

Para quem é o artigo?

O artigo pode ser de interesse para gerentes de projeto, diretores técnicos, líderes de equipe e todos os que de alguma forma se relacionam com a organização dos processos de desenvolvimento de aplicativos.

Isenção de responsabilidade:

Este artigo não é uma panacéia, mas apenas uma opinião puramente pessoal do autor (Alexey Klinov, chefe de segurança da informação da AGIMA).

Como tudo começou

A AGIMA está há muito envolvida no desenvolvimento abrangente de procedimentos de controle de qualidade e no departamento de controle de qualidade. Todos os nossos produtos passam por inúmeras verificações internas:

• use listas de verificação após cada etapa / sprint do desenvolvimento do produto;
• Cobrimos funcionalidades críticas de negócios com uma rede de autotestes;
• Tentamos cobrir o código com testes de unidade, tanto quanto possível;
• usamos analisadores de código que atendem aos padrões (por exemplo, para PHP é PSR 0-4, etc.);
• Realizamos testes de carga sem falhas.

Mais detalhes sobre nossos processos podem ser encontrados no artigo . Mas por que decidimos adicionar outra fronteira de teste?

Pelo cliente

Muitos clientes pesquisam vulnerabilidades por conta própria: usam scanners instrumentais ou realizam testes com caneta. De uma forma ou de outra, nosso código e projetos como um todo geralmente passam por uma variedade de verificações pelo cliente.
O número de verificações aumentou, os relatórios sobre os resultados da digitalização instrumental e dos testes com caneta se tornaram cada vez mais. O estudo, a reprodução, a aprovação e a correção de vulnerabilidades consumiram muitos recursos internos e podem demorar várias semanas.

De mão em mão quando alguém estava desenvolvendo um projeto

Às vezes, os projetos são herdados de outro contratado. Eles podem estar no estado de pré-venda e "em batalha". A responsabilidade pelo trabalho já está sobre nós, e todo o “carrinho” de bugs e vulnerabilidades, curiosamente, também.
Sugerimos que é mais eficiente e mais barato ter nossa própria experiência nisso.

O que atrapalhou?

Ao desenvolver, nos concentramos na qualidade da aplicação, na velocidade de seu comissionamento e custo. Adicionando elementos adicionais na forma de análise de código para vulnerabilidades, mais uma linha de teste ou funcionário afetará esses indicadores. Dada a baixa margem dos negócios, isso é fundamental para o desenvolvimento personalizado. Ao mesmo tempo, para otimizar custos, a abordagem do controle de segurança dos produtos deve ser universal e aplicada a todos os projetos. Mas os clientes geralmente não dizem "nos fazem a mesma aplicação que os caras de lá, apenas verdes". Os clientes desejam não apenas o design, mas também a funcionalidade. Além disso, cada setor de negócios tem suas próprias necessidades: os requisitos para aplicações no setor financeiro, medicina e varejo são diferentes. A equipe e a tecnologia em cada projeto podem ser muito diferentes.

Obviamente, o controle de segurança do produto melhora sua qualidade. Mas como a análise de segurança afetará o custo e o cronograma dos projetos?

Ao adicionar uma revisão adicional do código à estimativa, inicialmente tornamos o projeto mais caro e aumentamos o tempo de desenvolvimento, assim como em outros tipos de teste. Mas esse orçamento ainda teria que ser gasto, apenas de forma menos sistemática e mais penosa. De fato, o produto na saída é mais "limpo", o que reduz o nível de dívida técnica, elimina a necessidade de gastar muito tempo e recursos em aprimoramentos após testes com caneta e, consequentemente, o tempo para colocar o produto em produção é reduzido.
No futuro, no nosso caso, a implementação da análise de segurança se mostrou mais barata e rápida, levando em consideração todo o ciclo do projeto. Em alguns projetos, os custos foram reduzidos para 20%, inclusive reduzindo o tempo para localizar vulnerabilidades e eliminando-as antes mesmo da liderança da equipe de revisão de código.
Foi decidido encontrar a melhor maneira de implementar a segurança da informação em nossos processos de desenvolvimento.

Primeiros passos

Nossa visão sobre como melhorar a segurança do aplicativo:



A proteção WAF e DDoS são camadas adicionais de proteção no produto. E para nossos propósitos, precisamos de um analisador de código para vulnerabilidades e um teste de caneta.

Little cube

Escolhendo um analisador para iniciar, excluímos produtos caros pagos. Paramos no SonarQube - um analisador que possui uma versão shareware. Também existe uma versão em nuvem , mas a versão gratuita torna os projetos completamente abertos, o que, no nosso caso, é inaceitável.
Portanto, para iniciar - SonarQube Community Edition. Ele suporta 15 idiomas, incluindo Java, JavaScript, C #, PHP e Python. A solução é implantada rapidamente e não causa problemas especiais; isso é facilitado por um guia detalhado.



Sistema conveniente de diferenciação de direitos: você pode criar uma matriz de acesso a cada projeto.



O SonarQube permite observar a dinâmica do projeto e armazenar o histórico da análise. Nós mesmos podemos definir um limite de qualidade para cada projeto, o que nos permite otimizar a análise para diferentes projetos.





Testamos o produto em vários projetos:

1. Foi possível capturar várias vulnerabilidades não óbvias nos projetos atuais.
2. O tempo de implementação foi mínimo.
3. Garantimos que, dentro da estrutura do IC, o código seja retornado para revisão, indicando possíveis vulnerabilidades.

Decidimos que isso é suficiente para nossos empreendimentos.

O que vem a seguir?

Para nós mesmos, identificamos três abordagens que variam dependendo dos projetos e das necessidades dos clientes:

• Integração total ao processo de desenvolvimento (CI / CD).
• Auditoria de segurança nos pontos de verificação.
• Auditoria de segurança situacional ou única.

Integração total no processo de desenvolvimento

Integramos a solução no GitLab. Utilizou o CI / CD do GitLab para automatizar o lançamento de verificações. Isso exigia o plug-in gratuito do Sonar GitLab Plugin . O sistema notifica os desenvolvedores de confirmações que falham na verificação e adiciona comentários descrevendo a área do problema (tipo de vulnerabilidade, recomendações para corrigi-la e outras).
Um dos projetos implementou a integração com o Bitbucket e o Bamboo. Nesse caso, os plug-ins pagos Sonar para Bamboo e Sonar para Bitbucket Server eram necessários. Após a operação de teste, o cliente estava pronto para custos adicionais, a solução se encaixava perfeitamente na pilha tecnológica.



A opção ideal é quando os prazos, orçamento e cliente nos permitem integrar nossos processos de segurança no ciclo diário de trabalho com o código. Na prática, verificou-se que essa abordagem é relevante para o desenvolvimento e suporte a longo prazo de projetos com lançamentos frequentes.

Auditoria de segurança de ponto de verificação

Para nós, essa abordagem foi ideal para projetos em que os lançamentos são raros, por exemplo, uma vez por trimestre. A funcionalidade ou os requisitos do produto podem mudar durante a operação. Se você observar constantemente cada linha do código por segurança, gastará muito tempo extra naquelas partes do produto que nós e o cliente poderemos recusar posteriormente.

O que nos relacionamos com os pontos de controle:

• Marco lógico no desenvolvimento do MVP.
• Lançamento de uma versão específica do produto que contém funcionalidade crítica de interação do usuário.
• Uma versão específica, sprint ou um conjunto de sprints, que também possui funcionalidade crítica para interagir com o usuário.

Nos principais projetos, começamos a combinar análise integrada com auditorias de segurança nos pontos de interrupção. Assim, identificamos vulnerabilidades que podem passar despercebidas durante o processo de desenvolvimento.

Usando essa abordagem, reduzimos o número de iterações de depuração ao colocar o produto em operação comercial. Estamos preparando um conjunto comum de correções e melhorias, que inclui erros funcionais, vulnerabilidades de segurança da informação e requisitos de infraestrutura.

Coletamos estatísticas sobre custos de tempo com um procedimento integrado de validação de SI nos e sem pontos de controle. Medimos apenas as atividades de depuração e lançamento em um ambiente produtivo.
Com uma abordagem abrangente, em média, são necessárias duas iterações de depuração. Sua duração total é de ~ 15 a 20% do tempo total de desenvolvimento.
Ao conectar terceiros à validação de segurança da informação, foram obtidas uma média de duas iterações de depuração funcional e três de vulnerabilidades de segurança da informação / requisitos de infraestrutura. No total, isso representou ~ 45% do tempo total de desenvolvimento, excluindo o tempo gasto por terceiros, apenas do nosso lado.

Auditoria de segurança situacional ou única

Para projetos simples, decidimos aplicar a abordagem com uma verificação única de toda a base de código antes do lançamento final. O desembarque é suficiente para verificar uma vez antes do lançamento. Implementar a verificação de código em um processo ou fazer verificações intermediárias em tais projetos é caro e inútil.

Além disso, uma auditoria situacional começou a ser realizada em projetos que foram transferidos para nós de outros desenvolvedores. Antes de prosseguir com o desenvolvimento, minimizamos a dívida técnica existente do produto. Depois disso, determinamos qual abordagem de controle de segurança usaremos no desenvolvimento adicional do projeto.

É o resultado da varredura de um projeto que não é submetido a uma auditoria completa de bugs e segurança há vários anos:



Mais de 700 artefatos de vulnerabilidade! Obviamente, se você filtrar todos os falsos positivos e artefatos menores, deixando apenas bloqueadores e críticas, a imagem não será tão terrível. Mas esta é a bagagem da dívida técnica, que, em qualquer caso, precisa ser processada!



Classificamos as vulnerabilidades e compilamos um roteiro, onde observamos quantas iterações vulnerabilidades críticas precisam ser eliminadas. Depende do pedaço de código que eles afetam, que dados podem ser obtidos usando essas vulnerabilidades. Qual a probabilidade de um invasor explorar uma vulnerabilidade específica.

Nesse caso, passamos mais de 200 horas-homem "peneirando" e eliminando as vulnerabilidades encontradas, e somente depois disso começamos o desenvolvimento completo do produto. Às vezes é necessário resolver esses casos, pois estar na ignorância é muito mais caro.

Nós não paramos por aí:

• Análise adicionada à maioria dos projetos.
• As ferramentas de controle de segurança foram complementadas pelo appScreener da Rostelecom-Solar.
• Adicionado auditoria manual e teste de caneta para os principais projetos.
• Grupos de critérios e níveis de criticidade introduzidos para a funcionalidade implementada em termos de impacto na segurança do aplicativo.

Então, o que vem a seguir?

Os esforços para implementar a segurança da informação em processos de desenvolvimento personalizados nos beneficiaram:

• Reduzimos os riscos de reputação para nós mesmos e para nossos clientes, minimizando a possibilidade de invadir nossos aplicativos.
• Quase desaparecemos os longos estágios dos aplicativos de depuração após testes de penetração por organizações de terceiros.
• Aumentamos as competências dos funcionários no campo da segurança da informação e planejamos continuar a avançar nessa direção: crescer novos líderes em segurança, enriquecer nossa base de conhecimentos, refinar nossas abordagens e experimentar novas.
• Recebemos uma excelente vantagem competitiva em relação a outras empresas que fornecem serviços de desenvolvimento personalizados e não possuem competências em segurança da informação.

Quanto mais avançamos no aprimoramento da segurança da informação, mais vemos pontos de crescimento: adicione aos nossos procedimentos verificações não apenas das 10 principais OWASP e CWE / SANS, mas, por exemplo, agilize o rastreamento de boletins de segurança ou ensine nosso IC a usar o guia de segurança para nossas estruturas.

Já realizamos nosso primeiro evento de IB ( Rostelecom-Solar Business Dinner - AGIMA ), escrevemos este artigo e planejamos continuar trazendo novas práticas para o nosso mercado, como fizemos com o design adaptável em nosso tempo (consulte Adaptoz ou nosso dicionário adaptável). design , lançado em 2013) - foi conosco que essa tendência começou e agora se tornou essencialmente o padrão de fato. Queremos fazer o mesmo com a segurança da informação, porque "quando você ensina aos outros, aprende a si mesmo".