
Abordagem moderna para segurança da informação
Eu amo a segurança da informação. Por um lado, um negócio geralmente requer o lançamento de protótipos incompletos, implantados uma vez por hora. Por outro lado, é a fortaleza dura e inacessível dos oficiais de segurança da informação. Tudo depende deles. E mesmo os desenvolvimentos no campo da IoT, onde S é segurança, se tornam ainda mais confiáveis sob sua supervisão.
A questão-chave para estimar o diâmetro do
E uma lista. Todo mundo adora listas. Darei meu pequeno conjunto de software necessário, que ilumina muito minha vida cotidiana.
Se algo é chato, você precisa automatizar

A pirâmide de teste clássica. Em algum lugar na parte inferior estão vários testes de unidade que cobrem todos os tipos de pequenas coisas, como garantir que o aplicativo não trave se o usuário inserir sua senha em hindi. Ou enviou outra coisa estranha. E havia precedentes com "لُلُصّبُلُلصّبُررً ॣ ॣ h ॣ ॣ 冗" no iPhone, se você se lembra. Esse tipo de teste é ótimo para sua automação, mas cobre apenas casos estreitos que muitas vezes não fornecem uma imagem completa e confiança de que o aplicativo não fluirá em um local inesperado.
No topo, já é um teste totalmente manual. Além de verificar casos-padrão, pode proporcionar "criatividade livre", quando um especialista recebe a tarefa de quebrar algo de qualquer forma exótica ao seu gosto. Como sempre, esse tipo de abordagem criativa leva ao fato de que esse tipo de teste também é o mais caro. Não apenas em termos de dinheiro, mas também o notório time-to-market, quando você precisa lançar novos recursos na hora certa em uma reunião já prometida.
Um problema tradicional enfrentado por muitas empresas é a longa e triste coordenação com a segurança da informação em cada item. Não porque eles estejam tão zangados e hostis. Só que sua tarefa é minimizar os riscos. Assim, eles minimizam o máximo que podem, parando simultaneamente metade dos processos no gargalo de suas verificações. Na verdade, em tempos pré-Jail, quando você podia polir lentamente seu código, isso funcionava. E agora 47 protótipos incompletos de concorrentes com codificadores de macaco já serão lançados para sua solução polida da primeira versão. E isso é tudo. Você já perdeu o mercado, todos os usuários estão presos em outro Tick-Tock.
Pipeline para tudo
Na verdade, na maioria das vezes, o problema é a má integração dos processos de segurança da informação em pipelines já familiares aos desenvolvedores. Por alguma razão, cada push é acompanhado por muitas verificações do mesmo flake8 e mypy, é montado em um pacote próprio, carregado no contêiner do runner do GitLab e felizmente testado no Artifactory. Ou falha em um estágio e retorna para revisão.
E apenas a segurança da informação está freqüentemente sob uma lente de aumento com suas mãos a cada liberação, folheando o código e enfiando uma varinha nas portas abertas do aplicativo. Parece-me que uma das melhores soluções é mover a maior parte das verificações de segurança para um processo automatizado e limitar os testes manuais com o tempo. O IB reserva-se o direito de veto se encontrar uma vulnerabilidade crítica, mas, por padrão, o aplicativo entra em produção se não houver objeções de sua parte. Pode parecer assustador à primeira vista, mas essa estrutura de processo motiva a automatizar todos os procedimentos de rotina tanto quanto possível e gastar tempo apenas em coisas realmente complicadas.
Essas abreviações como DevSecOps e outros TriCeraTops me assustam um pouco, mas é exatamente isso que precisa ser organizado com mais frequência para reduzir custos de tempo. Vamos dar uma olhada em um exemplo de python. Vale a pena começar com linters. Eu acho que quase todo mundo parafusou em algumas variantes de linters básicos como flake8 e mypy. Eu ainda recomendaria a versão estendida do flake8 - wemake-python-styleguide.
É instalado e iniciado tradicionalmente:
pip install wemake-python-styleguide
flake8 your_module.py
O principal problema com este linter é que ele pode fazer você querer quebrar o monitor com o teclado a princípio. Especialmente em projetos antigos, é mais fácil queimar do que consertar. No entanto, se você excluir verificações desnecessárias, terá um controle bastante rígido sobre a qualidade do código subjacente.
Depois de verificarmos o próprio código quanto a construções tortas, baixa legibilidade e alta complexidade ciclomática, devemos executar o linter de segurança estática. Sim, em linguagens vagamente digitadas, esses linters não são tão bons, mas permitem que você identifique problemas típicos como password = 'qwerty123' no código. Você pode usar o mesmo bandido aqui .
Tudo isso funciona muito bem, mas o problema com as soluções gratuitas está mais frequentemente em bancos de dados de vulnerabilidade menos atualizados. Na maioria das vezes, faz sentido adicionar algo comosegurança .

Opções de checkout semelhantes de origem geralmente se integram perfeitamente com o mesmo GitLab corporativo.
Dito isso, geralmente há uma boa saída informativa para o console:
safety check --full-report

O ideal é que, depois de todas as manipulações, você tenha um pipeline completo, onde verifique passo a passo todos os requisitos de segurança de sua aplicação.

Verificações típicas de origem : verificação de
segredo git - verifique a ausência de segredos abertos no código
SCA - verifique se as dependências e bibliotecas externas estão livres de vulnerabilidades. É importante se você estiver congelando a versão antiga da biblioteca
SAST - análise de código estático para vulnerabilidades
Auditoria de contêiner - auditoria da imagem do contêiner que será usada para implantação. Eles também costumam estar cheios de buracos. Especialmente se você estiver usando sanduíches exóticos de muitas camadas variadas.
DAST - implantação de aplicativos, registro, login como um usuário legítimo e execução de ataques típicos no front-end
O que resta para a segurança da informação
Agora que livramos as
Haverá o mesmo arsenal eterno de ferramentas para análise, teste de rede e adivinhação de senha. Wireshark, hashcat, Hydra e outros utilitários nunca foram aposentados.
Mas mesmo entre ferramentas familiares, algo novo e às vezes bastante útil aparece. Vou sugerir que você preste atenção a alguns deles.
Nikto2
github.com/sullo/nikto
Nikto é um scanner de servidor da web de código aberto. Ele não está nada quieto. Sério, se você o lançou do seu local de trabalho e por 15 minutos ainda não ficou deitado de bruços no chão cercado pelo pessoal de segurança, você terá problemas com a detecção de intrusão.
O software executa testes complexos em servidores da web para muitos elementos, incluindo mais de 6.700 arquivos / programas potencialmente perigosos. Ele também verifica os itens de configuração do servidor, como configurações do servidor HTTP, e tenta identificar os servidores da Web e o software instalados. Itens de digitalização e plug-ins são atualizados com frequência e podem ser atualizados automaticamente.
Fuzzdb
Também é uma ferramenta muito legal para um ataque automatizado em aplicativos da web usando padrões e vulnerabilidades típicas. Ele ficará feliz em bombardear seu aplicativo com um monte de ataques padrão e, ao mesmo tempo, verificar se você esqueceu de cobrir o acesso ao painel de administração e aos arquivos de log com direitos reduzidos. Permite que você alivie muitas dores de cabeça e verificações de rotina.
Nmap + Vulners

Vulners é um agregador de todos os tipos de CVEs, boletins de segurança de fornecedores, exploits no Metasploit e simplesmente o resultado da captura manual de vulnerabilidades em fóruns temáticos. Basicamente, eles fornecem uma API para consultar seu banco de dados. Fiquei simplesmente cativado por seu plugin para o conhecido nmap, que imediatamente oferece um leque de vetores de ataque prontos para um serviço da web. Eu recomendo dar uma olhada mais de perto.
Algo como saída

Morte aos humanos - glória aos robôs!
Mas, falando sério, tente minimizar a rotina e passá-la para quem realmente deveria fazer isso - scripts e pipelines sem alma. E deixe as pessoas se envolverem na criatividade. Isso é mais correto.

