Pressa é inimiga da perfeição, e pode colocar em risco sistemas de todos os tipos

Nos últimos dias, o foco em segurança nunca esteve em tamanha evidência como atualmente. Qual é a empresa que possui algum produto ou serviço, que tenha ao menos algum site, aplicativo, ou alguma coisa relacionada que não pense de alguma forma em uma segurança digital?

Muita das vezes, vemos ataques ao Tribunal Superior Eleitoral (TSE), e risco de que hackers estejam acessando dados confidenciais de pessoas, do governo, dentre outros, mas e a segurança nesta questão aonde fica?

Precisamos pensar em segurança ao máximo possível, e como proteger nossas aplicações contra ações deste tipo, porém, é comum também ver que no Brasil não temos uma organização clara em desenvolvimento de projetos para que possamos seguir em frente e conquistar novos passos rumo à segurança, e prazos e datas correm risco de que projetos não sejam entregues dentro das datas.

Programadores e desenvolvedores pressionados para desenvolver algo em um prazo curto, ou que já estourou, acaba muita das vezes fazendo coisas erradas, seja por pressa, inimiga óbvia da perfeição, ou também porque a equipe selecionada não é especialista no produto ao qual está trabalhando, ou seja, coloca-se uma equipe que nunca trabalhou com algum determinado framework e cobra um prazo.

Com certeza, nos últimos tempos, em plena pandemia de Covid-19, as empresas na área de tecnologia estão realizando esforços enormes em busca de atualizar aplicativos, sites, e de conter ataques, estancar inúmeras tentativas de acessos indevidas, assim como também tentar mitigar enxugando o gelo nos acessos causados por falso positivo. Ou seja, colocam-se tantos equipamentos de segurança, gastam-se milhões para tentar mitigar a falha de desenvolvimento que foi feito às pressas para atender alguma demanda de prazo.

Prazo é inimigo de um bom sistema, e claro, um bom sistema feito com perfeição, não precisa, em teoria, de nenhum sistema de segurança à sua frente inspecionando nada, afinal, trabalha-se de forma blindada em sua própria arquitetura, mas é claro que sonhar com isso, atualmente é utopia, pois não podemos contar que a equipe de desenvolvimento sempre terá tempo suficiente para desenvolver tudo da forma correta. Erros ocorrem, e muitos erros ocorrem mesmo.

O risco para a empresa é que o custo do vazamento dos dados podem custar clientes que podem simplesmente ficar com receio de criar um cadastro, de comprar algo, ou de aplicar seu dinheiro e não ver o seu retorno. Um risco de um ataque, de uma exploração com sucesso, pode ser um pesadelo para qualquer organização em qualquer setor da economia.

Prazos, equipes desqualificadas que atuam em uma frente, e acabam lidando com outras frentes em um domínio de conhecimento desconhecido, podem colocar em risco tanto a qualidade da entrega do projeto, como também colocam em risco a empresa à exposição de dados, tudo como meta de atender um prazo do marketing, que não entende absolutamente nada de segurança, e quando a falha explodir, irão culpar a área de tecnologia.

Veja o caso do TSE, onde os votos em primeiro turno das eleições municipais tiveram problemas em seu "supercomputador", mas carecem de informações a respeito, falando apenas que foi uma falha na "Oracle". Vamos supor que a aplicação seja extremamente segura, não previram que poderia ter um ataque de DDoS? E se sim, não pensaram em uma camada de firewall para simplesmente rejeitar estes pacotes? E que tal fazer estes pacotes esperarem por uma resposta em um firewall disfarçado de sistema, fazendo com que ele leve 2, 3, 10 segundos para responder?

Veja bem, você tem uma aplicação que atende a porta 80, e ela processa os dados, e lhe responde. Você pode muito bem colocar um firewall à sua frente nesta porta 80, tanto para filtrar pacotes, como para encapsular o certificado SSL do site, fazendo um port-forward criptografado e abrindo apenas a porta 443 na internet.

Você recebe milhares de requisições SSL na porta 443, isto força o firewall a realizar handshake e processar o cabeçalho SSL, para só depois estabelecer comunicação, mas que tal você fazer uma aplicação que antes de chegar na porta 443 faça um sequenciamento de envio de pacotes para portas como por exemplo um esquema de chave, exemplo:

Endereço IP fictício 1.2.3.4 fez uma requisição na porta 443, mas antes disto, esta aplicação cliente fez chamadas na porta 32100, 32200 e 32556 contendo uma espécie de "ping".

Pode-se considerar liberar o acesso a porta 443 para todos os servidores que foram listados nas chamadas das portas acima? Pronto, temos um cenário mais complexo de ser atacado, afinal, o atacante não só precisa saber qual é o endereço IP da aplicação, qual porta, mas também tentar descobrir quais são as demais portas, e demais sequências para conseguir a devida liberação no firewall e conseguir passar pelas restrições.

Mas quem pensa em fazer um sistema de segurança no Brasil? Com certeza alguém que diga que quer um ícone mais bonito, uma tela colorida, e dizer de peito cheio que "nosso sistema não falha", nem imagina em investir em segurança como deveria.