Por Eric Helmer
Políticas sólidas de segurança sempre foram importantes, mas, com a contínua interconexão entre os mais variados negócios, os líderes de TI estão ainda mais preocupados com a questão. No entanto, esta maré crescente levou a um certo “pânico” e uma tentativa equivocada de cobrir todas as necessidades com subprodutos inadequados.
Muitos pensam que não há alternativas ao pagamento da tarifa de manutenção anual e aplicação de patches de correções de software. Essa percepção, porém, ignora o fato de que fabricantes de software corporativo não são empresas de segurança e, provavelmente, nunca serão. Os patches de software fornecidos pelos fabricantes de ERP são geralmente simples correções de bugs, e esses tipos de correções quase sempre figuram como uma forma lucrativa de “tapar o sol com a peneira”.
Você pode esperar tanto por um patch de segurança?
Normalmente, os fabricantes de software gerenciam os bugs para determinar sua validade e gravidade, o que na maioria das vezes é um processo árduo e demorado. Os fabricantes precisam identificar todas as áreas possíveis onde a biblioteca ou o código-base foi usado, quais plataformas foram afetadas e o histórico. Este é o momento em que podem descobrir que um bug já existe há muito tempo, até mesmo há 20 ou 30 anos. Na verdade, muitas vezes, o mesmo problema recebe novamente um patch, após anos de existência, pois alguma situação pode ter passado despercebida.
Saia do ciclo vicioso do patch de segurança
Quando finalmente um patch é lançado, começa a dor de cabeça para as organizações. A correção é normalmente um processo demorado e complicado, especialmente para grandes plataformas empresariais, onde as customizações dos sistemas podem parar de funcionar em função de um comportamento não esperado de um subproduto do patch.
Mesmo se a companhia tiver uma política de aplicação imediata do patch (o que é muito raro e mais provável que seja anual ou, na melhor das hipóteses, mensal), pode levar até um ano para que o patch seja baixado, instalado, testado em todo o ambiente e finalmente colocado em produção. Os clientes devem esperar os patches serem lançados, realizar rigorosos testes de regressão, fazer o QA, executar testes com o usuário final e consertar os problemas que os patches geraram multiplicado por cada instância de banco de dados ou aplicação na empresa. Tudo isso demanda muito tempo, é arriscado e caro. E quando algo similar surge novamente, os clientes são forçados a repetir todo este ciclo, que é longo e nada assertivo.
Um exemplo disso é a vulnerabilidade do Apache Struts, que levou à violação de dados da Equifax. Isso ocorreu devido a uma falha de desserialização insegura (CWE-502, uma das muitas outras falhas do CWE: 20, validação de entrada inadequada) predominante na maioria das aplicações hoje. E o patch que foi lançado para resolver o problema ainda não resolve nem a vulnerabilidade do CWE-502 nem do CWE-20, apenas endereça uma exposição (CVE-2017-5638). Enquanto isso, um novo patch foi lançado para endereçar o mesmo tipo de vulnerabilidade (CVE-2017-9805). É por isso que centenas de patches foram lançados para lidar com a falha descrita, mas a maioria foi ignorada.
Pense nos grandes casos de segurança ao longo dos anos: Marriott, Target, AdultFriendFinder, eBay etc, nenhum foi resolvido por um patch de fabricante. É mais provável que essas e outras empresas tenham sido afetadas por falta de atenção a configurações fracas, ameaças internas, negligência do administrador, políticas não aplicadas e assim por diante. Estas novas ameaças estão fazendo com que os clientes de ERP questionem se estão realmente seguros, dependendo dos patches dos fabricantes, que são complexos e, mesmo quando aplicados, tendem a ter um escopo limitado porque resolvem apenas o problema pontual e não a fragilidade como um todo. Deve haver (e há) uma maneira melhor.
O panorama geral da segurança
Soluções modernas de segurança endereçam quase todas as vulnerabilidades, e não apenas pontos específicos de exposição. Por exemplo, em vez de resolver um único problema de SQL injection e codificação para uma vulnerabilidade específica (estratégia de patch do fabricante), as soluções modernas mitigam o SQL injection como um todo.
Hoje, os CISOs e demais líderes que atuam na segurança da informação exigem estratégias modernas e mais econômicas, como proteções de banco de dados in-memory ou autoproteção em tempo real para middleware e aplicações, além de outras técnicas que oferecem maneiras muito mais eficazes e proativas de lidar com a segurança do software corporativo, tudo com reduções massivas no tempo de parada e na interrupção dos negócios. Os CISOs inteligentes aproveitam o uso dessas tecnologias como um controle comum ou controle compensatório para atender ou exceder as expectativas dos auditores de segurança onde o patching é impraticável ou mesmo não possível para o negócio.
*Eric Helmer, Chief Technology Officer para a Rimini Street
