Imagine um dia normal da vida do Lucas, que é Coordenador de TI de uma média empresa...

Era uma terça-feira, 9:00hs...

O Lucas chegou para trabalhar, cumprimentou o pessoal e foi direto para sua mesa.

Pegou um café, ligou o computador, entrou no Outlook e abriu a caixa de entrada. Leu uns 3 emails do chefe sobre algumas coisas que estavam andando. Descartou a maioria dos emails sem ler...era quase tudo spam mesmo.

O dia estava cheio... Então o telefone tocou.

O gerente da Contabilidade ligou reclamando que precisava acessar um novo site da Receita de algum estado, mas parece que o endereço direcionava para porta estranha, fora do padrão, 9443. 

Provavelmente o firewall ou filtro de URL no proxy estava bloqueando o acesso, por que as portas web liberadas eram a padrão 80 e 443.

Ok, rapidamente o Lucas criou uma regra no proxy para liberar o aceso na porta 9443, e mandou uma mensagem para o gerente da Contabilidade tentar acessar o site novamente. O gerente tentou mas infelizmente não funcionou. 

Então o Lucas liberou "temporariamente" a porta para acessar "sem proxy"...o dia estava corrido, depois ele poderia ver com mais calma como configurar isso.

Passou mais algum tempo e a empresa que fornece o ERP mandou email dizendo que precisava de um acesso remoto na rede, porque no dia anterior atualizou o módulo de RH e "deu problema". Então o Lucas criou uma VPN para o fornecedor acessar a rede e adicionou umas regras novas no firewall também para permitir acesso no ERP.

Perto do meio-dia o programador da empresa terceirizada que criou o site, mandou um WhatsApp desesperado por que não conseguia acessar o servidor web via SSH. 

O cara está conectado home-office e a VPN dele não funcionou. O gerente do marketing estava no seu pé cobrando para corrigir coisas no site institucional da empresa porque o prazo para lançar a nova campanha terminaria hoje.

Ok, tranquilo, isso é coisa fácil para o Lucas. Era só entrar no servidor da nuvem e criar uma regra para desenvodor acessar via SSH. 

Mas há um problema, o IP que o desenvolvedor do site é dinâmino...criar uma nova VPN iria demorar. Então o que o Lucas fez? Liberou temporariamente o acesso SSH para qualquer IP, afinal o cara precisava trabalhar...depois do almoço ele poderia revisar essa regra e ver isso com mais calma.

O Lucas também sabia que o programador iria mexer no site, então ele já gerou um snapshot do servidor. Se acontecesse algum problema, já teria um backup para voltar rapidamente.

A tarde o Lucas tinha reunião com o pessoal da operadora e o bicho iria pegar.  A diretoria estava reclamando das quedas dos links! Já foram 2 vezes esse mês.

Opa, chega a hora do almoço, hora do relax.

14hs: a reunião mal começou e o WhatsApp do Lucas não parou um minuto sequer. O pessoal do marketing queria um novo sub-domínio para enviar news e o Gerente do financeiro está reclamando da "lentidão" no ERP, provavelmente deve ser o banco de dados sobrecarregado ou o storage.

Durante a reunião, o Lucas já copiou a reclamação para o fornecedor do ERP, e mandou Whatsapp para outro analista da equipe criar o sub-domínio para o pessoal do Marketing

Terminou a reunião e o Lucas voltou para sua sala. Abriu o email viu que o fornecedor do ERP já resolveu o problema do banco de dados e o sub-domínio foi criado.

O Lucas começou a escrever o email para seu Gerente sobre o que foi falado na reunião, e também para formalizar com o pessoal da operadora o que ficou combinado. Respondeu mais alguns emails e mensagens do WhatsApp que estavam pendentes.

Eram quase 17:30. O Lucas lembrou de algumas configurações que fez. Acessou o webserver e viu que o programador do site ainda está trabalhando e iria precisar ficar conectado depois das 18hs no servidor com aquele acesso SSH.

Então pensou: "Quase no fim do expediente, não vou mexer em nada agora, amanhã no primeiro horário vejo essas coisas."

18:10 hrs..."bora pra casa"...mais um dia heróico!

Ok, nada de anormal com tudo isso que ocorreu no dia do Lucas. Quase todas as empresas tem um ambiente dinâmico onde a mudança no ambiente de TI é rotina.

O problema...

Todas essas coisas que aconteceram geraram mudanças no ambiente de TI, na nuvem e na rede.

Foi criada uma nova regra no firewall para a Contabilidade acessar o site sem proxy...isso pode causar problemas mais tarde? Será que outros usuários ou algum malware poderá usar essa regra para fazer "bypass" no filtro de web?

O fornecedor do ERP precisou acessar via RDP, será que esse acesso ficou aberto? 

O Lucas também fez um snapshot do site. Será que foi feito com criptografia? Será que esse snapshot ficou privado? Lembrando que o SSH no servidor web na nuvem também ficou aberto naquele dia, será que foi fechado mais tarde?

O sub-domínio foi criado para o Marketing. Alguém validou se está bem configurado? Pode haver vazamento de zones ou ataques de DNS spoofing...quem sabe?

O fornecedor do RH também precisou acessar, será que foi via RDP?  Será que esse acesso também ficou aberto?

Mudanças no ambiente é algo absolutamente normal, não há nada que se possa fazer em relação a isso. 

Novas demandas sempre vão existir e para a maioria das empresa burocratizar não dá...é ainda pior. Imagine que para cada solicitação fosse necessário formalizar, avaliar o risco de segurança, etc. O usuário quer e precisa ter a demanda atendida o mais breve possível...o negócio é mais importante.

Mas então o que fazer para garantir algum nível de segurança com tantas demandas?

O que fazer para que os analista não precisem ficar depois do horário só revisando regras e coisas que foram alteradas?

O que fazer checar se alguém esqueceu algum acesso aberto que pode oferecer risco?

O que fazer conferir se alguma configuração errada na nuvem pode gerar um vazamento de dados?

O que fazer para verificar se alguém esqueceu algum backup na nuvem sem criptografia e que pode vazar dados?

A solução...

Uma abordagem mais sensata é ter uma maneira de automatizar a verificação de falhas e alertar as brechas mais críticas.

Por exemplo, aquele acesso RDP que ficou aberto pode representar um risco em potencial para ataques de força bruta, ou mesmo por um ransomware que explore alguma falha protocolo RDP. Lembramos que o RDP tem histórico recente de falhas críticas que foram exploradas por ransomware.

O SSH exposto no webserver da nuvem, é um prato cheio para ataques de brute-force ou mesmo exploração de falhas conhecidas em hash fracos. 

Um snapshot sem criptografia pode não estar em compliance com a LGPD ou com a política de segurança da empresa. Isso sem falar das mais de 1.300 falhas de segurança em software publicadas todo mês!

"Quanto software bugado, sem atualização temos nos nossos sites e servidores?"

"Temos alguma brecha extremamente crítica?"

"Podemos ser invadidos através de alguma dessas falhas?"

"Os dados do site podem ser vazados devido a alguma falha?"

"Estamos usando criptografia corretamente na nuvem?

"Estamos em compliance com a LGPD?¨

O ScanX faz foi feito para isso...

Para varrer de forma automatizada os sites, servidores e a aplicações para detectar falhar conhecidas de software e configurações erradas, e que podem trazer problemas sérios de cibersegurança.

Com o alerta gerado pelo ScanX, pode-se por exemplo detectar aquele acesso RDP que ficou exporto ou um serviço aberto.

Detectar também um site com falha de segurança que ainda não foi atualizado.

Pode também detectar se a conta na AWS ou Azure está usando as melhores práticas de segurança de dados.

O ScanX consegue identificar uma falha de software conhecida e com isso a equipe pode priorizar e corrigir o que for mais crítico, antes que essa falha seja explorada por alguém mal intencionado na internet, por exemplo.

Em segurança dizemos:

"Aquilo que não é visto, não significa que não existe."

Essa é nossa visão do ScanX para TI:

Dar visibilidade para a equipe identificar, de forma automatizada e frequente, as falhas de segurança que surgem todo dia. E com isso priorizar e corrigir de forma mais possível, antes que um problema mais grave ocorra.

Bom trabalho!

ScanX Team.

PS: Veja também nosso FAQ completo para ter mais alguns insigts.