É sobre como você usa a tecnologia com segurança como engenheiro de software

O significado de segurança, no mundo digital, é sobre como proteger informações. A segurança é uma preocupação transversal que afeta todas as pessoas associadas às informações, sejam eles usuários que usam aplicativos digitais, desenvolvedores que desenvolveram aplicativos e todos os demais integrantes da equipe de software.

Os desenvolvedores de aplicativos anteriores tiveram que passar por um processo indolor de consertar muitos bugs de segurança por conta própria. Hoje em dia, o desenvolvimento de aplicativos está ficando sofisticado com ferramentas, frameworks e bibliotecas avançadas. Os desenvolvedores não precisam se preocupar muito em termos de segurança de aplicativos, por exemplo, nos dias em que a injeção de SQL era comum, embora consertar fosse mais fácil, as pessoas não percebiam, então o ORM decidiu abstraí-lo. Você deve ter adivinhado agora que não vamos discutir sobre como lidar com vulnerabilidades no código.

Se você observar o estado atual da segurança cibernética, verá que o maior número de ataques não são ataques técnicos, levados pelo uso de scanners de vulnerabilidade de última geração ou explorando vulnerabilidades conhecidas escrevendo algoritmos sofisticados, mas são ataques de engenharia social. É uma técnica enganosa que envolve humanos.

Também devido à crescente conscientização sobre a segurança cibernética, as pessoas não são vítimas de tais ataques facilmente, mas isso não significa que quem quer que seja a vítima, seja estúpido. Todo mundo comete um erro em sua vida em um ponto ou outro.

Uma das regras básicas do universo é que nada é perfeito. A perfeição simplesmente não existe … Sem imperfeição, nem você nem eu existiríamos

– Stephen Hawking

Neste artigo vamos discutir sobre como podemos evitar os simples erros cometidos por engenheiros de software, SWE não significa apenas desenvolvedores, sem nos tornarmos muito técnicos, o que pode levar a consequências catastróficas.

1. Faça a varredura de segredos em cada confirmação

Na maioria das vezes, vimos engenheiros de software mantendo segredos ou senhas diferentes em arquivos de configuração, como texto simples, isso por si só é considerado um antipadrão.

Ainda assim, as pessoas os mantêm em texto simples, dizendo que estão implementando código no Repositório Git Privado, mas você nunca sabe que alguém novo em sua equipe pode implementar um código em seu próprio repositório público (acredite, isso aconteceu comigo) por razões que eu não. não quero entrar (os humanos dobram as regras de colaboração).

Outro cenário poderia ser, você está trabalhando em POC que envolve ferramentas e plataformas que precisam de senhas ou segredos para acessar, como plataformas de nuvem, bancos de dados, APIs externas protegidas com chave de API e você envia o código para repositórios públicos.

Uma solução simples para esse problema pode ser o uso de ganchos Git , eles são uma ótima maneira de reduzir o fator humano para garantir que as verificações sejam sempre realizadas antes que o código seja confirmado ou enviado. O AWS Labs tem implementação de código aberto que pode ser encontrada aqui ou na Thoughtworks Talisman . Existem muitas outras implementações que você pode escolher, como Repo Supervisor , Git Hound etc.

Certifique-se de que cada membro da equipe, envolvido no trabalho com código, tenha esses utilitários instalados e configurados.

2. Verifique novamente o que você está instalando

Ataque de typosquatting ou URL Hijacking é um ataque de engenharia social em que os atores da ameaça se fazem passar por domínios legítimos para fins maliciosos, como fraude ou propagação de malware. Em palavras simples, é um ataque que aproveita erros de ortografia e erros de digitação.

Aqui estamos aplicando o mesmo princípio para dependências que instalamos em nossos aplicativos por gerenciadores de pacotes como npm, gemoupip.

Há uma tese realmente ótima que explica como esse ataque pode ser eficaz, para obter acesso a um computador se uma pessoa cometer um erro de digitação ao instalar um pacote usando gerenciadores de pacotes. É uma porcentagem surpreendente de ~ 43% (de um total de 17.289 ) computadores que deram acesso administrativo ao hacker.

Outro ataque surpreendente de Typosquatting com Pacotes é realizado com imagens Docker. Muitas organizações de software estão executando seu código em toneladas de contêineres do docker e os desenvolvedores tentam reutilizar as imagens do docker existentes do DockerHub como registros. Embora esses registros possam fazer a varredura em busca de pacotes maliciosos nas imagens do docker, os invasores certificam-se de baixar o conteúdo malicioso em tempo de execução para evitar ser sinalizado em varreduras de vulnerabilidade. Você pode ver neste artigo

Uma análise dinâmica das imagens publicamente disponíveis no Docker Hub descobriu que 51% tinham vulnerabilidades críticas e cerca de 6.500 das 4 milhões de imagens mais recentes podem ser consideradas maliciosas.

Embora pareça horrível, existem algumas medidas básicas que podemos tomar para evitar esses ataques.
1. Verifique novamente os nomes dos pacotes antes de instalá-los
2. Antes de importar qualquer pacote no código-fonte, tente passar pelos problemas de segurança abertos do pacote / biblioteca e verifique o código por conta própria
3. Remova quaisquer dependências não utilizadas do código
4. Antes de puxar qualquer imagem do docker da ferramenta de código aberto, verifique o Dockerfile e veja se ele está instalando todos os pacotes legítimos e, no tempo de execução, não puxará nenhum código malicioso

3. Não publique detalhes do projeto em sites públicos

É muito difícil encontrar um engenheiro de software que não conheça o StackOverflow, sem trocadilhos. Estamos muito acostumados a pesquisar nossos problemas de software nesses sites para obter ajuda de outras pessoas.

Quando estamos buscando ajuda em tais sites, às vezes precisamos colocar alguns detalhes como código, configurações etc. para dar um contexto do problema que estamos enfrentando e é quando o erro pode acontecer ao copiar / colar informações internas de seu aplicativo de forma negligente. como segredos (como mencionado no ponto 1), teste os detalhes de login

Observações semelhantes são feitas em algumas ferramentas de gerenciamento de projeto, onde engenheiros de software gerenciam suas informações relacionadas ao projeto. O relato detalhado pode ser lido aqui, onde mostra uma pesquisa simples no Google de segredos ou senhas direcionados a painéis públicos no Trello, como aplicativos de gerenciamento de projetos podem ser uma fonte de dados para hackers.

Para evitar o vazamento de detalhes internos do software, certifique-se de criar um trecho de código simples que imite o problema que você está enfrentando em seu software, sem usar nenhuma variável real, função ou nomes de classe e apenas focado no problema para o qual você está procurando solução.

Para o segundo problema, certifique-se de converter todas as suas placas públicas em privadas e, se isso não for possível, certifique-se de não adicionar nenhuma informação sensível aos cartões. Você pode ficar de olho nos fóruns executando as consultas de pesquisa do Google mencionadas no artigo, periodicamente.

4. Não copie / cole código às cegas

Estou tomando a liberdade aqui e modificando a Lei de Postel para ” ser conservador tanto no que você envia quanto no que você aceita”. Como mencionamos anteriormente em sites públicos, você posta suas perguntas e espera que alguém as responda em termos de snippet de código e referências a exemplos que podem resolver os problemas.

Pode haver pessoas que postam intencionalmente ou não o trecho de código que pode quebrar seu sistema ou introduzir vulnerabilidade em seu código, que hackers posteriores podem usar para explorar seu software. Não acredita em mim? Aqui está um blog de StackOverflow mostrando diferentes vulnerabilidades em códigos de amostra postados como respostas.

Veja este outro exemplo em que 5 linhas simples de código quebraram todos os processadores Intel

Sempre que você estiver procurando por um código de amostra na Internet, certifique-se de entender o que ele está fazendo. Não tome cegamente as respostas como verdade e execute-as em suas máquinas ou inclua no código-fonte do seu software. Se você não consegue descobrir o que uma parte específica do código está fazendo, fique longe dela.

5. Verifique se há vulnerabilidades nas dependências

Como discutimos no ponto 3, os invasores podem fazer upload de pacotes com nomes semelhantes de pacotes populares legítimos. Neste cenário, os pacotes são legítimos, mas contêm algumas vulnerabilidades relatadas no NVD ( National Vulnerability Database ) e podem afetar seu software.

Hoje em dia os sistemas SCM integram essas varreduras, por exemplo, GitHub, onde escaneiam o código em sua plataforma e notificam os usuários se houver alguma vulnerabilidade relatada na versão específica. Não só isso, mas também sugerem a versão do pacote para incluir em sua fonte que remove essa vulnerabilidade específica. Este é mais um motivo, entre outras centenas, para usar o SCM.

OWASP Foundation (Open Web Application Security Project) também fornece plug-ins / ferramentas de verificação de dependência para verificar dependências vulneráveis ​​em seu projeto.

TL; DR

Evitar ou corrigir problemas de segurança em um software não é apenas uma tarefa dos profissionais de segurança cibernética, mas de todas as pessoas envolvidas no ciclo de vida do software. Não é apenas um desenvolvedor que pode tornar o software vulnerável, porque não se trata apenas de código. Você deve sempre ter cuidado ao colocar qualquer coisa de seu software em sites públicos, bem como ao aceitar qualquer coisa da Internet. Suspeite de tudo o que você vai adicionar no projeto que está obtendo da web aberta, aceite apenas se você tiver verificado todos os aspectos dele.
De acordo com o Princípio de Peter Parker ” Com grande poder vêm grandes responsabilidades “