Como já comentamos em uma postagem anterior, o desenvolvimento de produtos de software modernos é praticamente impossível sem o uso de componentes de código aberto. Mas, nos últimos anos, os riscos associados a isso tornaram-se cada vez mais diversos, complexos e numerosos. Devemos considerar que, primeiro, as vulnerabilidades afetam a infraestrutura e o código de uma empresa mais rapidamente do que são corrigidas; segundo, os dados são incompletos e pouco confiáveis; e, terceiro, malware pode estar escondido em componentes populares. Portanto, não basta simplesmente verificar os números de versão e solicitar que a equipe de TI corrija os problemas. O gerenciamento de vulnerabilidades deve ser expandido para abranger políticas de download de software, proteções para assistentes de IA e todo o pipeline de criação de software.

Um conjunto confiável de componentes de código aberto

A principal característica de uma solução é impedir o uso de código vulnerável e malicioso. As seguintes medidas devem ser implementadas:

• Ter um repositório interno de artefatos. A fonte única de componentes para desenvolvimento interno precisa ser um repositório unificado no qual os componentes são admitidos somente após uma série de verificações.
• Fazer uma triagem rigorosa dos componentes. Isso inclui verificações de versões conhecidas do componente, versões vulneráveis e maliciosas conhecidas, data de publicação, histórico de atividades e reputação do pacote e de seus autores. É obrigatório verificar todo o conteúdo do pacote, incluindo instruções de compilação, casos de teste e outros dados auxiliares. Para filtrar o registro durante a ingestão, use verificadores de código aberto especializados ou uma solução de segurança abrangente de carga de trabalho na nuvem.
• Fixar versões de dependências. Os processos de compilação, as ferramentas de IA e os desenvolvedores não devem usar modelos (como “o mais recente”) ao especificar versões. As compilações do projeto precisam ser baseadas em versões verificadas. Ao mesmo tempo, as dependências com versões fixas devem ser atualizadas com frequência para as versões verificadas mais recentes que mantêm a compatibilidade e não contêm vulnerabilidades conhecidas. Isso reduz significativamente o risco de ataques à cadeia de suprimentos por meio do comprometimento de um pacote conhecido.

Aperfeiçoamento dos dados de vulnerabilidades

Para identificar vulnerabilidades com mais eficácia e priorizá-las de forma adequada, uma organização precisa estabelecer vários processos de TI e segurança:

• Enriquecimento de dados de vulnerabilidade. Dependendo das necessidades da organização, isso é necessário para enriquecer as informações combinando dados do NVD, EUVD, BDU, GitHub Advisory Database e osv.dev, ou para comprar um feed de inteligência de vulnerabilidades comercial no qual os dados já estão agregados e enriquecidos. Em ambos os casos, também vale a pena monitorar os feeds de inteligência de ameaças para rastrear tendências de exploração reais e obter um entendimento do perfil dos invasores que visam vulnerabilidades específicas. A Kaspersky fornece um feed de dados especializado especificamente focado em componentes de código aberto.
• Análise detalhada da composição do software. As ferramentas especializadas de análise de composição de software (SCA) permitem o mapeamento correto da cadeia de dependências no código-fonte aberto para realizar o inventário completo das bibliotecas que estão sendo usadas e descobrir componentes desatualizados ou sem suporte. Os dados sobre componentes íntegros também são úteis para enriquecer o registro de artefatos.
• Identificação do abandonware. Mesmo que um componente não apresente vulnerabilidades formais e o encerramento do suporte ainda não tenha sido declarado oficialmente, o processo de verificação deve sinalizar os componentes que não receberam atualizações há mais de um ano. Isso garante uma análise separada e uma possível substituição, assim como ocorre com os componentes em EOL (fim da vida útil).

Proteção do código e dos agentes de IA

As atividades dos sistemas de IA usados na codificação devem ser agrupadas em um conjunto abrangente de medidas de segurança: desde a filtragem de dados de entrada até o treinamento do usuário:

• Restrições de recomendações de dependências. Configure o ambiente de desenvolvimento para garantir que os agentes e assistentes de IA consultem apenas componentes e bibliotecas do registro de artefatos confiável. Se eles não contiverem as ferramentas corretas, o modelo deve acionar uma solicitação para incluir a dependência no registro em vez de extrair algo do PyPI que apenas corresponda à descrição.
• Filtragem das saídas do modelo. Apesar dessas restrições, tudo o que for gerado pelo modelo também deve ser verificado para garantir que o código de IA não contenha dependências desatualizadas, sem suporte, vulneráveis ou inventadas. Essa verificação deve ser integrada diretamente no processo de aceitação do código ou no estágio de preparação da compilação. Ela não substitui o processo de análise estática tradicional: as ferramentas SAST ainda devem ser incorporadas no pipeline de CI/CD.
• Treinamento do desenvolvedor. As equipes de TI e de segurança devem estar extremamente familiarizadas com as características dos sistemas de IA, seus princípios operacionais e erros comuns. Para conseguir isso, os funcionários devem completar um curso de treinamento especializado, adaptados às suas funções específicas.

Remoção sistemática de componentes em EOL

Se os sistemas de uma empresa utilizarem componentes de código aberto desatualizados, deve-se adotar uma abordagem sistemática e consistente para lidar com as vulnerabilidades. Existem três métodos principais para fazer isso:

• Migração. Este é o método mais complexo e caro para uma organização, pois envolve a substituição total de um componente, seguida pela adaptação, reescrita ou substituição dos aplicativos construídos sobre ele. Decidir sobre uma migração é muito mais difícil quando se exige uma revisão geral de todo o código interno. Isso costuma afetar os componentes principais: é impossível migrar facilmente do Node.js 14 ou do Python 2.
• Suporte de longo prazo (LTS). Existe um mercado de serviços de suporte dedicado para projetos legados de larga escala. Às vezes, isso envolve uma bifurcação do sistema legado mantido por desenvolvedores de terceiros; em outros casos, equipes especializadas fazem o backport de patches que corrigem vulnerabilidades específicas em versões mais antigas e sem suporte. A transição para o LTS geralmente exige custos de suporte contínuos, mas, em muitos casos, isso ainda pode ser mais econômico do que uma migração completa.
• Controles compensatórios. Com base nos resultados de análises detalhadas, é possível criar um conjunto de medidas de segurança abrangentes para mitigar o risco de exploração das vulnerabilidades de um produto legado. Tanto a eficácia quanto a viabilidade econômica dessa abordagem dependem da função do software na organização.

Os departamentos de segurança, TI e negócios devem trabalhar juntos para escolher um desses três métodos para cada componente abandonado ou com EOL documentado e refletir a escolha feita nos registros de ativos e SBOMs da empresa.

Gerenciamento de vulnerabilidades de código aberto baseado em risco

Todos os métodos listados acima reduzem o volume de softwares e componentes vulneráveis que entram na organização, o que simplifica a detecção e a correção de falhas. Apesar disso, é impossível eliminar todos os defeitos: o número de aplicativos e componentes está crescendo muito rápido.

Portanto, é essencial priorizar as vulnerabilidades com base nos riscos reais que elas representam. O modelo de avaliação de risco deve ser expandido para considerar as características do código aberto, além de responder às seguintes perguntas:

• A ramificação do código vulnerável é realmente executada no ambiente da organização? Deve-se realizar uma análise de acessibilidade das vulnerabilidades descobertas. Muitos snippets de código defeituosos nunca são realmente executados na implementação específica da organização, fazendo com que seja impossível explorar a vulnerabilidade. Certas soluções de SCA podem realizar esta análise. Esse mesmo processo permite avaliar um cenário alternativo: o que acontece se os procedimentos ou componentes vulneráveis forem removidos completamente do projeto? Às vezes, esse método de remediação é surpreendentemente indolor.
• O defeito está sendo explorado em ataques reais? Há um PoC disponível? As respostas a essas perguntas fazem parte de estruturas de priorização padrão, como EPSS, mas o rastreamento deve ser realizado em um conjunto muito mais amplo de fontes de inteligência.
• A atividade de criminosos cibernéticos foi relatada nesse registro de dependência ou em componentes relacionados e semelhantes? Estes são fatores adicionais para a priorização.

A consideração desses fatores permite que a equipe aloque recursos de forma eficaz e corrija os defeitos mais perigosos primeiro.

A transparência nunca sai de moda

O padrão de segurança para softwares de código aberto só vai continuar subindo. As empresas que desenvolvem aplicativos, mesmo que para uso interno, enfrentarão pressões regulatórias que exigem segurança cibernética documentada e verificável nos seus sistemas. De acordo com as estimativas dos especialistas da Sonatype, 90% das empresas em todo o mundo já se enquadram em um ou mais requisitos que as obrigam a fornecer provas da confiabilidade do software que usam. Portanto, os especialistas consideram a transparência “o pilar fundamental da segurança da cadeia de suprimento de software”.

Ao controlar o uso de componentes e aplicativos de código aberto, enriquecer a inteligência contra ameaças e fazer o monitoramento rigoroso dos sistemas de desenvolvimento orientados por IA, as organizações podem introduzir as inovações que tanto desejam, ao mesmo tempo em que atingem o padrão elevado definido por reguladores e clientes.

Para implementar programas eficazes de cibersegurança e manter a equipe de segurança profundamente integrada a todos os processos de negócios, o CISO precisa demonstrar regularmente o valor desse trabalho para a alta administração. Isso requer fluência na linguagem dos negócios, porém, uma armadilha perigosa espreita os mais desavisados.  Profissionais de segurança e executivos geralmente usam as mesmas palavras, mas para coisas totalmente diferentes. Às vezes, vários termos semelhantes são usados de forma intercambiável. Assim, talvez não fique muito claro para a alta administração quais são as ameaças que a equipe de segurança está tentando mitigar, qual é o nível real de ciber-resiliência da empresa ou onde o orçamento e os recursos estão sendo alocados. Portanto, antes de apresentar painéis elegantes ou calcular o ROI dos programas de segurança, vale a pena esclarecer essas importantes nuances terminológicas.

Ao esclarecer esses termos e construir um vocabulário compartilhado, o CISO e o conselho de administração podem melhorar significativamente a comunicação e, em última análise, fortalecer a postura de segurança geral da organização.

Por que o vocabulário de cibersegurança é importante para a gestão

As interpretações variadas dos termos representam mais do que uma simples inconveniência, e as consequências podem ser bastante significativas. A falta de clareza em relação aos detalhes pode levar a:

• Investimentos mal alocados. A administração pode aprovar a compra de uma solução de confiança zero sem perceber que, na prática, isso é apenas parte de um programa mais abrangente, de longo prazo e com um orçamento significativamente maior. O dinheiro é gasto, mas os resultados esperados pela equipe gestora nunca são alcançados. Da mesma forma, em relação à migração para a nuvem, a equipe gestora pode supor, num primeiro momento, que essa solução transfere automaticamente toda a responsabilidade de segurança ao provedor e, então, num segundo momento, o orçamento de segurança da nuvem é rejeitado.
• Aceitação cega do risco. As lideranças das unidades de negócios podem aceitar os riscos de cibersegurança sem ter uma compreensão completa do impacto potencial.
• Falta de governança. Sem entender a terminologia, a administração não pode fazer as perguntas certas, ou mesmo as mais difíceis, ou ainda, atribuir as áreas de responsabilidade de forma eficaz. Quando ocorre um incidente, muitas vezes os proprietários de negócios acreditam que a segurança estava inteiramente sob responsabilidade do CISO, enquanto o CISO, na verdade, não tinha autoridade para influenciar os processos de negócios.

Ciber-risco x risco de TI

Muitos executivos acreditam que a cibersegurança é uma questão puramente técnica que pode ser repassada à equipe de TI. Embora a importância da cibersegurança para os negócios seja indiscutível e os incidentes cibernéticos tenham sido classificados como um dos principais riscos para os negócios, pesquisas mostram que muitas organizações ainda não conseguem envolver as lideranças sem perfil técnico nas discussões sobre cibersegurança.

Os riscos de segurança da informação geralmente são tratados de maneira conjunta com as preocupações de TI, como tempo de atividade e disponibilidade do serviço.  Na realidade, o ciber-risco é um risco estratégico de negócios, ligado à continuidade, às perdas financeiras e aos danos à reputação.

Por outro lado, os riscos de TI geralmente são de natureza operacional, afetando a eficiência, a confiabilidade e o gerenciamento de custos. Em linhas gerais, a resposta a incidentes de TI é tratada inteiramente pela equipe de TI. Os principais incidentes de cibersegurança, no entanto, têm um escopo muito mais amplo: exigem o envolvimento de quase todos os departamentos e têm um impacto de longo prazo na organização sob vários aspectos, inclusive no que diz respeito à reputação, conformidade regulatória, relacionamento com o cliente e saúde financeira geral.

Conformidade x segurança

A cibersegurança está integrada aos requisitos regulatórios em todos os níveis, isto é, desde as diretivas internacionais, como NIS2 e GDPR, até as diretrizes do setor para transferência de dados além das fronteiras, como PCI DSS, além de imposições departamentais específicas. Assim, a equipe gestora da empresa geralmente percebe as medidas de cibersegurança como caixas de seleção de conformidade, acreditando que, uma vez que os requisitos regulatórios sejam atendidos, os problemas de cibersegurança poderão ser considerados resolvidos. Essa mentalidade pode ser fruto de um esforço consciente para minimizar os gastos com segurança (a administração acredita que não precisa fazer mais do que o necessário) ou advir de um mal-entendido sincero (a empresa está passando por uma auditoria ISO 27001, por isso não acredita que haja possibilidade de ser hackeada).

Na realidade, a conformidade está atendendo aos requisitos mínimos de auditores e reguladores governamentais em um momento específico. Infelizmente, o histórico de ciberataques em larga escala em grandes organizações prova que os requisitos “mínimos” são chamados assim por um motivo. Para uma proteção real contra ciberameaças modernas, as empresas devem melhorar continuamente suas estratégias e medidas de segurança de acordo com as necessidades específicas de um determinado setor.

Ameaça, vulnerabilidade e risco

Esses três termos são frequentemente usados como sinônimos, o que leva a conclusões errôneas feitas pela equipe gestora. Eis o raciocínio: “Há uma vulnerabilidade crítica no nosso servidor? Isso significa que se trata de um risco crítico!” Para evitar o pânico ou, inversamente, a inércia, é essencial usar esses termos com precisão e entender como eles se relacionam entre si.

Uma vulnerabilidade é uma fraqueza, ou seja, uma “porta aberta”. Isso significa que pode haver uma falha no código do software, um servidor configurado incorretamente, uma sala de servidores desbloqueada ou um funcionário que abre todos os anexos de e-mail.

Uma ameaça é algo que pode causar um incidente. A causa pode ser um agente malicioso, um malware ou até mesmo um desastre natural. Uma ameaça é o fator que pode “atravessar aquela porta aberta”.

O risco é a possível perda. É a avaliação cumulativa da probabilidade de um ataque bem-sucedido e o que a organização pode perder como resultado disso (o impacto).

As conexões entre esses elementos são melhor explicadas por meio de uma fórmula simples:

Risco = (ameaça × vulnerabilidade) × impacto

Isso pode ser ilustrado da seguinte forma. Imagine que uma vulnerabilidade crítica com uma classificação de gravidade máxima seja descoberta em um sistema desatualizado. No entanto, esse sistema está desconectado de todas as redes, fica em uma sala isolada e está sendo gerenciado por apenas três profissionais competentes. A probabilidade de um invasor alcançar o sistema é próxima de zero. Por outro lado, a falta de autenticação de dois fatores nos sistemas de contabilidade cria um risco real e elevado, resultante de uma alta probabilidade de ataque e de um possível dano significativo.

Resposta a incidentes, recuperação de desastres e continuidade dos negócios

A percepção da equipe gestora sobre as crises de segurança muitas vezes é simplista. Eis o raciocínio: “Se formos atingidos por um ransomware, bastará ativar o plano de recuperação de desastres de TI e fazer a restauração por meio do backup”. No entanto, combinar esses conceitos e também os processos é extremamente perigoso.

A resposta a incidentes (IR) é de responsabilidade da equipe de segurança ou de contratados especializados. O trabalho dessas equipes é localizar a ameaça, expulsar o invasor da rede e impedir que o ataque se espalhe.

A recuperação de desastres (DR) é uma tarefa de engenharia de TI. É o processo de restauração de servidores e dados de backups após a conclusão da resposta ao incidente.

A continuidade dos negócios (BC) é uma tarefa estratégica para a alta administração. Ela consiste em um plano, ou seja, a maneira como a empresa continuará atendendo clientes, enviando mercadorias, pagando compensações e mantendo o diálogo com a imprensa enquanto os sistemas principais ainda estiverem off-line.

Se a equipe gestora se concentrar apenas na recuperação, a empresa não terá um plano de ação para o período mais crítico de tempo de inatividade.

Conscientização sobre segurança x cultura de segurança

As lideranças em todos os níveis supõem algumas vezes que a simples realização de treinamentos de segurança garante resultados. Eis o raciocínio: “Os funcionários passaram no teste anual, então, agora, eles não clicarão em um link de phishing”. Infelizmente, contar apenas com treinamentos organizados pelas equipes de RH e de TI não será o suficiente. A eficácia requer a mudança de comportamento da equipe, o que é impossível sem o envolvimento da equipe gestora do negócio.

Conscientização é conhecimento. Um profissional sabe o que é phishing e entende a importância de senhas complexas.

A cultura de segurança tem a ver com padrões comportamentais. É aquilo que um funcionário faz em uma situação estressante ou quando ninguém está olhando. A cultura não é moldada por testes, mas por um ambiente onde o relato de erros é seguro, e a identificação e a prevenção de situações possivelmente perigosas são práticas comuns. Se um profissional teme a punição, ele ocultará um incidente. Em uma cultura saudável, um e-mail suspeito será encaminhado para o SOC, ou ainda, alguém que esquece de bloquear o computador receberá um toque do colega, o que acaba gerando um vínculo ativo na cadeia de defesa.

Detecção x prevenção

As lideranças empresariais muitas vezes pensam de forma ultrapassada, como uma “muralha da fortaleza”: “Compramos sistemas de proteção caros, portanto, não deve haver nenhuma maneira de sermos hackeados. Se ocorrer um incidente, isso significa que o CISO falhou”. Na prática, impedir 100% dos ataques é tecnicamente impossível e inviável do ponto de vista econômico. A estratégia moderna é construída sobre um equilíbrio entre a cibersegurança e a eficácia dos negócios. Em um sistema equilibrado, os componentes focados na detecção e prevenção de ameaças funcionam em conjunto.

A prevenção desvia ataques automatizados em massa.

O Detection and Response ajuda a identificar e neutralizar ataques mais profissionais e direcionados que conseguem contornar as ferramentas de prevenção ou explorar vulnerabilidades.

Atualmente, o principal objetivo da equipe de cibersegurança não é garantir a invulnerabilidade total, mas detectar um ataque em um estágio inicial e minimizar o impacto nos negócios. Para mensurar o sucesso aqui, o setor normalmente usa métricas, como tempo médio de detecção (MTTD) e tempo médio de resposta (MTTR).

Filosofia de confiança zero x produtos de confiança zero

O conceito de confiança zero, que implica “nunca confiar, sempre verificar” para todos os componentes da infraestrutura de TI, há muito tempo é reconhecido como relevante e eficaz para a segurança corporativa. Ele requer a verificação constante de identidade (contas de usuário, dispositivos e serviços) e contexto para cada solicitação de acesso de acordo com a suposição de que a rede já foi comprometida.

No entanto, a presença de “confiança zero” no nome de uma solução de segurança não significa que uma organização pode adotar essa abordagem da noite para o dia simplesmente comprando o produto.
A confiança zero não é um produto que se pode “ativar”, mas sim uma estratégia arquitetônica e uma jornada de transformação de longo prazo. A implementação da confiança zero requer a reestruturação dos processos de acesso e o refinamento dos sistemas de TI para garantir a verificação contínua da identidade e dos dispositivos. Comprar software sem alterar os processos não terá um efeito significativo.

Segurança da nuvem x segurança na nuvem

Ao migrar os serviços de TI para a infraestrutura em nuvem, como AWS ou Azure, muitas vezes existe a ilusão de que ocorrerá uma transferência de risco total. Eis o raciocínio: “Pagamos ao provedor, então, agora, a segurança será uma dor de cabeça para eles”. Esse raciocínio é equivocado e perigoso, pois se trata de uma interpretação errônea daquilo que é conhecido como o Modelo de responsabilidade compartilhada.

A segurança da nuvem é responsabilidade do provedor. Ele protege os data centers, os servidores físicos e o cabeamento.

A segurança na nuvem é responsabilidade do cliente.

As discussões sobre orçamentos para projetos em nuvem e seus aspectos de segurança devem ser acompanhadas por exemplos da vida real. O provedor protege o banco de dados contra acesso não autorizado de acordo com as configurações feitas pelos funcionários do cliente. Se os funcionários deixarem um banco de dados aberto ou usarem senhas fracas, ou ainda, se a autenticação de dois fatores não estiver ativada para o painel do administrador, o provedor não poderá impedir que indivíduos não autorizados baixem as informações: um tipo de notícia muito comum. Portanto, o orçamento para esses projetos deve levar em conta as ferramentas de segurança em nuvem e o gerenciamento de configuração feito pela empresa.

Verificação de vulnerabilidades x teste de penetração

As lideranças geralmente confundem as verificações automatizadas, que se enquadram na higiene cibernética, com a avaliação de ativos de TI quanto à resiliência contra ataques sofisticados. Eis o raciocínio: “Por que pagar aos hackers por um teste de penetração quando executamos o verificador toda semana?”

A verificação de vulnerabilidades analisa uma lista específica de ativos de TI com o objetivo de encontrar vulnerabilidades conhecidas. Para simplificar, é como se um segurança estivesse fazendo a ronda para verificar se as janelas e portas do escritório estão trancadas.

O teste de penetração (pentesting) é uma avaliação manual para avaliar a possibilidade de uma violação no mundo real, explorando vulnerabilidades. Para continuar a analogia, é como contratar um ladrão experiente para tentar invadir o escritório.

Um não substitui o outro, e para entender sua verdadeira postura de segurança, uma empresa precisa das duas ferramentas.

Ativos gerenciados x superfície de ataque

Um equívoco comum e perigoso diz respeito ao escopo da proteção e à visibilidade geral mantida pelas equipes de TI e de segurança. Eis um chavão comum nas reuniões: “A lista de inventário do nosso hardware é precisa. Estamos protegendo tudo o que possuímos”.

Os ativos gerenciados de TI são os itens que o departamento de TI comprou, configurou e consegue visualizar em seus relatórios.

Uma superfície de ataque é qualquer coisa acessível aos invasores: qualquer possível ponto de entrada na empresa. Isso inclui Shadow IT (serviços em nuvem, aplicativos de mensagens pessoais, servidores de teste, etc.), que, basicamente, é qualquer método que os funcionários usam para burlar os protocolos oficiais a fim de acelerar ou simplificar o trabalho. Muitas vezes, são esses os ativos “invisíveis” que se tornam o ponto de entrada para um ataque, pois a equipe de segurança não pode proteger aquilo que desconhece.

Milhões de sistemas de TI, sendo que alguns deles são industriais e outros de IoT, podem começar a se comportar de forma imprevisível em 19 de janeiro. As possíveis falhas incluem: falhas no processamento pagamentos com cartão; alarmes falsos de sistemas de segurança; operação incorreta de equipamentos médicos; falhas nos sistemas automatizados de iluminação, aquecimento e abastecimento de água; e muitos tipos de erros mais ou menos graves. O problema é que… isso acontecerá em 19 de janeiro de 2038. Não que isso seja motivo para relaxar, muito pelo contrário! O tempo restante para providenciar os preparativos talvez seja insuficiente. A causa dessa infinidade de problemas será um estouro nos números inteiros que armazenam data e hora. Embora a causa raiz do erro seja simples e clara, corrigi-lo exigirá esforços extensos e sistemáticos em todos os níveis : de governos e organismos internacionais a organizações e indivíduos.

O padrão informal da Época Unix

A Época Unix é o sistema de cronometragem adotado pelos sistemas operacionais Unix que se tornou popular em todo o setor de TI. Ele conta os segundos de 00:00:00 UTC em 1º de janeiro de 1970, considerado o ponto zero. Qualquer momento no tempo é representado como o número de segundos que se passaram desde aquela data. Para datas anteriores a 1970, são usados valores negativos. Essa abordagem foi escolhida pelos desenvolvedores do Unix por sua simplicidade, em vez de armazenar o ano, mês, dia e hora separadamente, apenas um único número é necessário. Isso facilita operações como classificar ou calcular o intervalo entre datas. Hoje, a Época Unix é usada muito além dos sistemas Unix: em bancos de dados, linguagens de programação, protocolos de rede e em smartphones executando iOS e Android.

A bomba-relógio Y2K38

Inicialmente, quando o Unix foi desenvolvido, foi tomada a decisão de armazenar o tempo como um inteiro com sinal de 32 bits. Isso permitia representar um intervalo de datas de aproximadamente 1901 a 2038. O problema é que, em 19 de janeiro de 2038, às 03:14:07 UTC, esse número atingirá seu valor máximo (2.147.483.647 segundos) e sofrerá um estouro, tornando-se negativo, fazendo com que os computadores se “teletransportem” de janeiro de 2038 para 13 de dezembro de 1901. Em alguns casos, no entanto, uma “viagem no tempo” mais curta pode acontecer, até o ponto zero, que é o ano de 1970.

Esse evento, conhecido como “problema do ano 2038”, “Epochalypse” ou “Y2K38”, poderá ocasionar falhas em sistemas que ainda usam a representação de tempo de 32 bits, como terminais POS, de sistemas integrados e roteadores, passando por automóveis, até equipamentos industriais. Os sistemas modernos resolvem esse problema usando 64 bits para armazenar o tempo. Isso estende o intervalo de datas para centenas de bilhões de anos no futuro. No entanto, milhões de dispositivos com datas de 32 bits ainda estão em operação e precisarão ser atualizados ou substituídos antes da chegada do “dia Y”.

Neste contexto, 32 e 64 bits se referem especificamente ao formato de armazenamento de data. Só porque um sistema operacional ou processador é de 32 bits ou 64 bits, isso não significa automaticamente que ele armazene a data em seu formato de bits “nativo”. Além disso, muitos aplicativos armazenam datas de maneiras completamente diferentes e podem ser imunes ao problema Y2K38, independentemente de sua quantidade de bits.

Nos casos em que não há necessidade de tratar datas anteriores a 1970, a data é armazenada como um número inteiro não assinado de 32 bits. Esse tipo de número pode representar datas de 1970 a 2106, portanto, o problema chegará em um futuro mais distante.

Diferenças do problema do ano 2000

O infame problema do ano 2000 (Y2K) do final do século 20 era semelhante. Naquelas circunstâncias, os sistemas que armazenavam o ano como dois dígitos poderiam confundir a nova data com o ano 1900. Tanto os especialistas quanto a mídia temiam um apocalipse digital, mas, no fim, houve apenas numerosas manifestações isoladas que não resultaram falhas catastróficas globais.

A principal diferença entre Y2K38 e Y2K é a escala da digitalização em nossas vidas. O número de sistemas que precisarão de atualização é muito maior do que o número de computadores no século 20, e a contagem de tarefas e processos diários gerenciados por computadores está além do cálculo. Enquanto isso, o problema Y2K38 já foi, ou será muito em breve, corrigido em computadores e sistemas operacionais comuns com atualizações de software simples. No entanto, os microcomputadores que gerenciam aparelhos de ar-condicionado, elevadores, bombas, fechaduras eletrônicas e linhas de montagem industriais podem muito bem continuar operando pela próxima década com versões de software desatualizadas e vulneráveis ao Y2K38.

Possíveis problemas do Epochalypse

A passagem da data para 1901 ou 1970 afetará sistemas diferentes, de maneiras diferentes. Em alguns casos, como em um sistema de iluminação programado para ligar todos os dias às 19h, a programação poderá passar completamente despercebida. Em outros sistemas que dependem de carimbos de data/hora completos e precisos, uma falha completa poderá ocorrer – por exemplo, no ano 2000, terminais de pagamento e catracas de transporte público pararam de funcionar. Casos cômicos também são possíveis, como a emissão de uma certidão de nascimento com uma data em 1901. Muito pior seria a falha de sistemas críticos, como o desligamento completo de um sistema de aquecimento ou a falha de um sistema de análise de medula óssea em um hospital.

A criptografia ocupa um lugar especial no Epochalypse. Outra diferença fundamental entre 2038 e 2000 é o uso generalizado de criptografia e assinaturas digitais para proteger todas as comunicações. Os certificados de segurança geralmente falham na verificação se a data do dispositivo estiver incorreta. Isso significa que um dispositivo vulnerável seria eliminado da maioria das comunicações, mesmo que seus aplicativos de negócios principais não tenham nenhum código que manipule incorretamente a data.

Infelizmente, o espectro completo de consequências só poderá ser determinado por meio de testes controlados de todos os sistemas, com a análise separada de uma potencial cascata de falhas.

A exploração maliciosa do Y2K38

As equipes de TI e InfoSec devem tratar o Y2K38 não como um simples bug de software, mas como uma vulnerabilidade que poderá ocasionar várias falhas, inclusive a negação de serviço. Em alguns casos, ela poderá até mesmo ser explorada por agentes maliciosos. Para fazer isso, eles precisarão ter a capacidade de manipular a hora no sistema de destino. Isso é possível em pelo menos dois cenários:

• Interferência nos dados do protocolo NTP ao fornecer ao sistema invadido um servidor de tempo falso
• Falsificação do sinal de GPS, caso o sistema dependa da hora via satélite

A exploração desse erro é mais provável em sistemas OT e IoT, onde as vulnerabilidades são tradicionalmente lentas para serem corrigidas e as consequências de uma falha podem ser muito mais substanciais.

Um exemplo de uma vulnerabilidade facilmente explorável relacionada à contagem de tempo é CVE-2025-55068 (CVSSv3 8.2, CVSSv4 base 8.8) nos consoles de medidor de tanque de combustível Dover ProGauge MagLink LX4. A manipulação do tempo pode causar uma negação de serviço no posto de gasolina e bloquear o acesso ao painel de gerenciamento da Web do dispositivo. Esse defeito ganhou seu próprio alerta da CISA.

O status atual da atenuação do Y2K38

Os parâmetros de resolução para o problema do Y2K38 foram estabelecidos com êxito nos principais sistemas operacionais. O kernel do Linux adicionou suporte para o tempo de 64 bits, mesmo em arquiteturas de 32 bits, a partir da versão 5.6, em 2020, e o Linux de 64 bits sempre foi protegido desse problema. A família BSD, macOS e iOS usam o tempo de 64 bits em todos os dispositivos modernos. Todas as versões do Windows lançadas no século 21 não são suscetíveis ao Y2K38.

A situação no armazenamento de dados e no nível do aplicativo é muito mais complexa. Sistemas de arquivos modernos, como ZFS, F2FS, NTFS e ReFS foram desenvolvidos com carimbos de data/hora de 64 bits, enquanto sistemas mais antigos como ext2 e ext3 permanecem vulneráveis. O Ext4 e o XFS exigem que sinalizadores específicos sejam ativados (inode estendido para ext4 e bigtime para XFS), além disso, eles podem necessitar da conversão off-line de sistemas de arquivos existentes. Nos protocolos NFSv2 e NFSv3, o formato de armazenamento de tempo desatualizado persiste. O cenário é igualmente fragmentado nos bancos de dados, o tipo TIMESTAMP do MySQL é intrinsecamente limitado ao ano de 2038 e exige migração para DATETIME, enquanto os tipos de carimbo de data/hora padrão do PostgreSQL são seguros. Para aplicativos escritos em C, os caminhos foram criados para usar o tempo de 64 bits em arquiteturas de 32 bits, mas todos os projetos precisam de recompilação. Linguagens como Java, Python e Go normalmente usam tipos que evitam o estouro, mas a segurança dos projetos compilados depende da possibilidade de interação com bibliotecas vulneráveis escritas em C.

Um grande número de sistemas de 32 bits, dispositivos integrados e aplicativos permanecem vulneráveis até que eles sejam reconstruídos e testados e, em seguida, tenham as atualizações instaladas por todos os usuários.

Várias organizações e entusiastas estão tentando sistematizar informações sobre isso, mas os esforços estão fragmentados. Consequentemente, não há um “banco de dados de vulnerabilidades Y2K38 comum” disponível (1, 2, 3, 4, 5).

Abordagens para correção do Y2K38

As metodologias criadas para priorizar e corrigir vulnerabilidades são diretamente aplicáveis ao problema do ano de 2038. O principal desafio consiste no fato de que nenhuma ferramenta contemporânea pode criar uma lista exaustiva de software e hardware vulneráveis. Portanto, é essencial atualizar o inventário de ativos de TI corporativos, garantir que ele seja enriquecido com informações detalhadas sobre firmware e software instalado e, em seguida, investigar sistematicamente a questão da vulnerabilidade.

A lista pode ser priorizada de acordo com a criticidade dos sistemas de negócios e com os dados na pilha de tecnologia na qual cada sistema está construído. As próximas etapas são: estudar o portal de suporte do fornecedor, fazer perguntas diretas aos fabricantes de hardware e software sobre seu status Y2K38 e, como último recurso, fazer a verificação por meio de testes.

Ao testar sistemas corporativos, é fundamental tomar precauções especiais:

• Nunca teste os sistemas que estão em produção.
• Crie um backup de dados imediatamente antes do teste.
• Isole o sistema em teste das comunicações, para que ele não interfira em outros sistemas da organização.
• Caso a alteração da data use NTP ou GPS, verifique e confirme se os sinais de teste do 2038 não podem alcançar outros sistemas.
• Após o teste, defina os horários de volta para a hora correta nos sistemas e documente minuciosamente todos os seus comportamentos observados.

Caso um sistema seja considerado vulnerável ao Y2K38, uma linha do tempo de correção deverá ser solicitada ao fornecedor. Caso uma correção seja impossível, planeje uma migração; felizmente, o tempo que nos resta ainda permite a atualização de sistemas bastante complexos e caros.

A coisa mais importante para enfrentar o Y2K38 é não pensar nele como um problema futuro distante cuja solução pode facilmente esperar mais cinco a oito anos. É altamente provável que já não tenhamos tempo suficiente para erradicar completamente o defeito. No entanto, dentro de uma organização com seu parque tecnológico, o planejamento cuidadoso e a abordagem sistemática para resolver o problema permitirão realmente fazer tudo isso em tempo hábil.

Invasores frequentemente exploram contas de teste desatualizadas e sem uso ou acabam encontrando armazenamentos em nuvem acessíveis publicamente que contêm dados críticos, já um pouco “empoeirados”. Em alguns casos, um ataque explora uma vulnerabilidade em um componente de aplicativo que, na verdade, havia recebido um patch, digamos, há dois anos. Ao ler relatórios de violações de segurança, um padrão comum se repete: os ataques se apoiam em algo desatualizado: um serviço, um servidor, uma conta de usuário… Elementos da infraestrutura corporativa de TI que, por vezes, saem do radar das equipes de TI e de segurança. Na prática, tornam-se ativos não gerenciados, inúteis ou simplesmente esquecidos. Esses “zumbis da TI” geram riscos à segurança da informação, à conformidade regulatória e resultam em custos operacionais desnecessários. Em geral, trata-se de um elemento da TI invisível com uma diferença fundamental: ninguém quer, conhece ou se beneficia desses ativos.

Neste artigo, buscamos identificar quais ativos exigem atenção imediata, como reconhecê-los e como deve ser estruturada a resposta.

Servidores físicos e virtuais

Prioridade: alta. Servidores vulneráveis funcionam como pontos de entrada para ataques cibernéticos e continuam consumindo recursos, ao mesmo tempo que geram riscos de conformidade regulatória.

Prevalência: alta. Servidores físicos e virtuais costumam ficar órfãos em grandes infraestruturas após projetos de migração ou depois de processos de fusões e aquisições. Servidores de teste que deixam de ser usados após a entrada em produção de projetos de TI, assim como servidores Web de projetos obsoletos operando sem domínio associado, também são frequentemente esquecidos. A dimensão do problema é ilustrada por estatísticas da autoridade certificadora Let’s Encrypt: em 2024, metade das solicitações de renovação de domínio partiu de dispositivos que já não estavam associados ao domínio solicitado. Estima-se que existam cerca de um milhão de dispositivos como esses no mundo.

Detecção: o departamento de TI precisa implementar um processo automatizado de Descoberta e Reconciliação (Automated Discovery and Reconciliation – AD&R), que combine resultados de varreduras de rede e inventários em nuvem com dados da Base de Dados de Gerenciamento de Configuração (Configuration Management Database – CMDB). Esse processo permite a identificação oportuna de informações desatualizadas ou conflitantes sobre ativos de TI e ajuda a localizar os próprios ativos esquecidos.

Esses dados devem ser complementados por verificações de vulnerabilidades externas que abranjam todos os endereços IP públicos da organização.

Resposta: estabelecer um processo formal e documentado para a retirada de operação ou descontinuação de servidores. Esse processo deve incluir a verificação da migração completa dos dados e a posterior destruição comprovada das informações armazenadas no servidor. Após essas etapas, o servidor pode ser desligado, reciclado ou reaproveitado. Até que todos os procedimentos sejam concluídos, o servidor deve ser movido para uma sub-rede isolada e em quarentena.

Para mitigar esse problema em ambientes de teste, implemente um processo automatizado para sua criação e retirada de operação. Um ambiente de teste deve ser criado no início de um projeto e desmontado após um período predefinido ou depois de um certo tempo de inatividade. Reforce a segurança dos ambientes de teste, garantindo seu isolamento rigoroso em relação ao ambiente principal (de produção) e proibindo o uso de dados reais de negócios não anonimizado nos testes.

Contas de usuários, serviços e dispositivos esquecidos

Prioridade: crítica. Contas inativas e com privilégios elevados são alvos preferenciais de invasores que buscam estabelecer persistência na rede ou ampliar seu acesso dentro da infraestrutura.

Prevalência: muito alta. Contas técnicas de serviços, contas de prestadores de serviço e contas não personalizadas estão entre as mais frequentemente esquecidas.

Detecção: realizar análises regulares do diretório de usuários (Active Directory, na maioria das organizações) para identificar todos os tipos de contas que não apresentaram atividade por um período definido (um mês, um trimestre ou um ano). Paralelamente, recomenda-se revisar as permissões atribuídas a cada conta e remover aquelas excessivas ou desnecessárias.

Resposta: após validação com o responsável pelo serviço na área de negócio ou com o gestor do colaborador, contas desatualizadas devem ser simplesmente desativadas ou excluídas. Um sistema abrangente de Identity and Access Management (IAM) oferece uma solução escalável para esse desafio. Nesse modelo, a criação, exclusão e atribuição de permissões às contas são fortemente integradas aos processos de RH.

No caso de contas de serviço, também é essencial revisar regularmente tanto a robustez das senhas quanto as datas de expiração dos tokens de acesso, realizando a rotação quando necessário.

Repositórios de dados esquecidos

Prioridade: crítica. Dados mal controlados em bancos de dados acessíveis externamente, armazenamentos em nuvem e lixeiras, bem como em serviços corporativos de compartilhamento de arquivos, inclusive os considerados “seguros”, foram uma das principais fontes de grandes vazamentos em 2024–2025. Os dados expostos nesses incidentes frequentemente incluem digitalizações de documentos, prontuários médicos e informações pessoais. Como consequência, esses incidentes de segurança também resultam em penalidades por não conformidade com regulamentações como a HIPAA, o GDPR e outros marcos de proteção de dados que regem o tratamento de informações pessoais e confidenciais.

Prevalência: alta. Dados de arquivo, cópias de dados mantidas por prestadores de serviço e versões legadas de bancos de dados de migrações de sistemas anteriores costumam permanecer fora de controle e acessíveis por anos, ou até décadas, em muitas organizações.

Detecção: dada a enorme variedade de tipos de dados e métodos de armazenamento, é essencial utilizar uma combinação de ferramentas para a descoberta:

• Subsistemas nativos de auditoria das principais plataformas de fornecedores, como AWS Macie e Microsoft Purview
• Soluções especializadas de Data Discovery e de Gerenciamento da Postura de Segurança de Dados
• Análise automatizada de logs de inventário, como o S3 Inventory

Infelizmente, essas ferramentas têm utilidade limitada quando um prestador de serviços cria um repositório de dados dentro de sua própria infraestrutura. O controle dessa situação exige cláusulas contratuais que concedam à equipe de segurança da organização acesso aos armazenamentos relevantes do fornecedor, complementadas por serviços de inteligência de ameaças capazes de detectar conjuntos de dados expostos publicamente ou roubados associados à marca da empresa.

Resposta: analisar os logs de acesso e integrar os armazenamentos identificados às ferramentas de DLP e CASB para monitorar seu uso, ou confirmar que estão de fato abandonados. Utilizar os recursos disponíveis para isolar com segurança o acesso a esses repositórios. Se necessário, criar um backup seguro e, em seguida, excluir os dados. No nível das políticas organizacionais, é fundamental estabelecer prazos de retenção para diferentes tipos de dados, determinando seu arquivamento automático e exclusão ao término do período definido. As políticas também devem definir procedimentos para o registro de novos sistemas de armazenamento e proibir explicitamente a existência de dados sem responsável que estejam acessíveis sem restrições, senhas ou criptografia.

Aplicativos e serviços não utilizados em servidores

Prioridade: média. Vulnerabilidades nesses serviços aumentam o risco de ataques cibernéticos bem-sucedidos, dificultam os esforços de aplicação de patches e desperdiçam recursos.

Prevalência: muito alta. Os serviços geralmente são ativados por padrão durante a instalação de servidores, permanecem após os testes e as etapas de configuração, continuam em execução muito tempo depois que o processo de negócios que eles apoiavam ter se tornado obsoleto.

Detecção: por meio de auditorias regulares das configurações de software. Para que a auditoria seja eficaz, os servidores devem seguir um modelo baseado em funções, no qual cada função de servidor tenha uma lista correspondente de softwares. Além da CMDB, um amplo conjunto de ferramentas auxilia nesse processo, como ferramentas focadas em conformidade de políticas e endurecimento de sistemas, a exemplo do OpenSCAP e do Lynis; ferramentas multifuncionais como o OSQuery; scanners de vulnerabilidades como o OpenVAS; e analisadores de tráfego de rede.

Resposta: realizar revisões periódicas das funções dos servidores em conjunto com seus responsáveis de negócio. Quaisquer aplicações ou serviços desnecessários identificados em execução devem ser desativados. Para minimizar esse tipo de ocorrência, implemente o princípio do menor privilégio em toda a organização e utilize imagens base endurecidas ou templates de servidores para construções padrão. Isso garante que nenhum software supérfluo seja instalado ou habilitado por padrão.

APIs desatualizadas

Prioridade: alta. APIs são frequentemente exploradas por invasores para exfiltrar grandes volumes de dados sensíveis e para obter acesso inicial à organização. Em 2024, o número de ataques relacionados a APIs aumentou 41%, com invasores mirando especificamente APIs desatualizadas, já que elas costumam disponibilizar dados com menos verificações e restrições. Um exemplo disso foi o vazamento de 200 milhões de registros do X/Twitter.

Prevalência: alta. Quando um serviço migra para uma nova versão de API, a versão antiga frequentemente permanece operacional por um longo período, sobretudo se ainda for utilizada por clientes ou parceiros. Essas versões obsoletas geralmente deixam de ser mantidas, o que faz com que falhas de segurança e vulnerabilidades em seus componentes não recebam patches.

Detecção: no nível de WAF ou NGFW, é essencial monitorar o tráfego direcionado a APIs específicas. Isso ajuda a detectar anomalias que podem indicar exploração ou exfiltração de dados e também identificar APIs que obtêm tráfego mínimo.

Resposta: para APIs identificadas com baixo nível de atividade, colaborar com as partes interessadas do negócio para desenvolver um plano de retirada de operação e migrar os usuários remanescentes para versões mais recentes.

Em organizações com um grande portfólio de serviços, esse desafio é melhor enfrentado com o uso de uma plataforma de gerenciamento de APIs, aliada a uma política formalmente aprovada de ciclo de vida de APIs. Essa política deve incluir critérios bem definidos para a descontinuação e aposentadoria de interfaces de software desatualizadas.

Software com dependências e bibliotecas desatualizadas

Prioridade: alta. É nesse ponto que se escondem vulnerabilidades críticas de grande escala, como a Log4Shell, capazes de comprometer toda a organização e gerar problemas de conformidade regulatória.

Prevalência: muito alta, especialmente em sistemas corporativos de gestão em larga escala, sistemas de automação industrial e softwares desenvolvidos sob medida.

Detecção: utilizar uma combinação de sistemas de gerenciamento de vulnerabilidades (VM/CTEM) e ferramentas de análise de composição de software (SCA). No desenvolvimento interno, é obrigatório empregar scanners e sistemas de segurança abrangentes integrados ao pipeline de CI/CD, a fim de evitar que o software seja construído com componentes desatualizados.

Resposta: as políticas da empresa devem exigir que as equipes de TI e de desenvolvimento atualizem sistematicamente as dependências de software. No desenvolvimento de soluções internas, a análise de dependências deve fazer parte do processo de revisão de código. No caso de softwares de terceiros, é fundamental auditar regularmente o estado e a antiguidade das dependências.

Para fornecedores externos de software, a atualização de dependências deve ser um requisito contratual, com impacto direto nos prazos de suporte e nos orçamentos dos projetos. Para viabilizar essas exigências, é essencial manter uma lista de materiais de software (SBOM) sempre atualizada.

Você pode ler mais sobre práticas de remediação de vulnerabilidades eficazes e oportunas em um post separado no blog.

Sites esquecidos

Prioridade: média. Ativos Web esquecidos podem ser explorados por invasores para campanhas de phishing, hospedagem de malware ou aplicação de golpes usando a marca da organização, causando danos reputacionais. Em casos mais graves, podem resultar em vazamentos de dados ou servir como ponto de partida para ataques direcionados à própria empresa. Um subconjunto específico desse problema envolve domínios esquecidos que foram usados para atividades pontuais, expiraram e não foram renovados, tornando-se disponíveis para compra por terceiros.

Prevalência: alta, especialmente no caso de sites lançados para campanhas de curta duração ou atividades internas pontuais.

Detecção: o departamento de TI deve manter um registro centralizado de todos os sites públicos e domínios, validando o status de cada um junto aos respectivos responsáveis em base mensal ou trimestral. Além disso, scanners ou ferramentas de monitoramento de DNS podem ser utilizados para rastrear domínios associados à infraestrutura de TI da empresa. Uma camada adicional de proteção é oferecida por serviços de inteligência de ameaças, capazes de identificar de forma independente quaisquer sites associados à marca da organização.

Resposta: estabelecer uma política de desligamento programado de sites após um período fixo ao término de seu uso ativo. Implementar um sistema automatizado de registro e renovação de DNS para evitar a perda de controle sobre os domínios da empresa.

Dispositivos de rede não utilizados

Prioridade: alta. Roteadores, firewalls, câmeras de vigilância e dispositivos de armazenamento em rede que permanecem conectados, mas sem gerenciamento e sem patches aplicados, constituem uma plataforma ideal para o lançamento de ataques. Esses dispositivos esquecidos frequentemente abrigam vulnerabilidades e quase nunca contam com monitoramento adequado (não há integração com EDR ou SIEM), ao mesmo tempo em que ocupam uma posição privilegiada na rede, oferecendo aos invasores um caminho facilitado para escalar ataques contra servidores e estações de trabalho.

Prevalência: média. Dispositivos costumam ser deixados para trás durante mudanças de escritório, atualizações da infraestrutura de rede ou a criação de espaços de trabalho temporários.

Detecção: utilizar as mesmas ferramentas de inventário de rede mencionadas na seção sobre servidores esquecidos, além de auditorias físicas regulares para comparar os resultados das verificações de rede com os equipamentos efetivamente conectados. A verificação ativa da rede pode revelar segmentos inteiros não mapeados e conexões externas inesperadas.

Resposta: dispositivos sem responsável definido geralmente podem ser desconectados da rede de forma imediata. No entanto, é preciso cautela: a higienização desses equipamentos exige o mesmo nível de cuidado aplicado à desativação de servidores, a fim de evitar vazamentos de configurações de rede, senhas, gravações de vídeo corporativas e informações semelhantes.

A implementação de redes de longa distância definidas por software (Software-Defined Wide Area Networks, SD-WANs) aumenta a eficiência operacional, reduz custos e melhora a segurança. Esses impactos são tão significativos que, às vezes, podem ser observados em escala nacional. De acordo com o artigo The Transformative Impact of SD-WAN on Society and Global Development (O impacto transformador das SD-WANs na sociedade e no desenvolvimento global) publicado no International Journal for Multidisciplinary Research, a adoção dessa tecnologia pode resultar em aumento de 1,38% no PIB de países em desenvolvimento. No nível corporativo, os efeitos são ainda mais evidentes. Por exemplo, na fabricação industrial moderna e profundamente digitalizada, pode reduzir o tempo de inatividade não planejado em 25%.

Além disso, os projetos de implementação de SD-WAN não apenas proporcionam um rápido retorno do investimento, como também continuam a oferecer benefícios adicionais e maior eficiência conforme a solução recebe atualizações e novas versões são lançadas. Para demonstrar isso, apresentamos o novo Kaspersky SD-WAN 2.5 e seus recursos mais relevantes.

Algoritmos otimizados de redirecionamento de tráfego

Esse é um recurso clássico de SD-WAN e uma das principais vantagens competitivas da tecnologia. O roteamento do tráfego depende da natureza e da localização do aplicativo corporativo, mas também leva em conta as prioridades atuais e as condições da rede: em alguns casos, a confiabilidade é essencial; em outros, a velocidade ou a baixa latência são o fator decisivo. A nova versão do Kaspersky SD-WAN aprimora o algoritmo e passa a incluir dados detalhados sobre a perda de tráfego em cada caminho possível. Isso garante o funcionamento estável de serviços críticos em redes geograficamente distribuídas, por exemplo, ao reduzir falhas em videoconferências nacionais de grande escala. O mais importante é que esse aumento de confiabilidade vem acompanhado da redução da carga de trabalho de engenheiros de rede e equipes de suporte, já que o processo de adaptação de rotas é completamente automatizado.

Encaminhamento condicional de DNS

Esse recurso otimiza a velocidade de resolução de nomes de domínio e ajuda a manter as políticas de segurança para diferentes tipos de aplicativos. Por exemplo, as solicitações relacionadas à infraestrutura em nuvem do MS Office são encaminhadas diretamente do escritório local à CDN da Microsoft, enquanto os nomes de servidores da rede interna são resolvidos por meio do servidor DNS corporativo. Essa abordagem melhora significativamente a velocidade de estabelecimento das conexões e elimina a necessidade de configurar manualmente os roteadores em cada escritório. Em vez disso, uma única política unificada é suficiente para toda a rede.

Alterações programadas de configuração de CPE

Qualquer reconfiguração de rede em larga escala aumenta o risco de interrupções (mesmo que breves) e falhas. Para garantir que esse tipo de evento não prejudique processos críticos de negócios, qualquer alteração de política no Kaspersky SD-WAN pode ser programada para um horário específico. Quer alterar as configurações de roteadores em cem escritórios ao mesmo tempo? Programe a alteração para as 2h no horário local ou para a manhã de sábado. Isso elimina a necessidade de a equipe regional de TI estar fisicamente presente durante a implementação.

Depuração simplificada de BGP e OSPF

A análise do roteamento BGP agora pode ser realizada inteiramente pela interface gráfica do orquestrador. Surgiu um loop de roteamento repentinamente em algum ponto entre os escritórios de Milão e Paris? Em vez de acessar cada equipamento em todos os escritórios e nós intermediários via SSH, você agora pode identificar e resolver o problema por meio de uma única interface, reduzindo significativamente o tempo de inatividade.

Substituição fácil de CPE

Se o equipamento de rede em um escritório precisar ser substituído, agora é possível manter todas as configurações existentes ao substituí-lo. O técnico no escritório simplesmente conecta a nova unidade CPE, e o orquestrador do Kaspersky SD-WAN restaura automaticamente todas as políticas e túneis no dispositivo. Isso oferece vários benefícios imediatos: reduz significativamente o tempo de inatividade; a substituição pode ser realizada por um técnico sem conhecimento aprofundado de protocolos de rede; e diminui consideravelmente a probabilidade de falhas adicionais causadas por erros de configuração manual.

Diagnóstico de LTE

Embora frequentemente seja o canal de comunicação corporativa mais rápido e econômico de implantar, o LTE apresenta uma desvantagem: a instabilidade. Tanto a cobertura celular quanto a velocidade operacional podem variar com frequência, exigindo que os engenheiros de rede tomem providências, como realocar o CPE para uma área com melhor sinal. Agora, você pode tomar essas decisões com base em dados de diagnóstico coletados diretamente pelo orquestrador. Ele exibe os parâmetros de serviço dos dispositivos LTE conectados, incluindo o nível de intensidade do sinal.

Gerenciamento de falhas de energia

Para empresas com os requisitos mais rigorosos de tolerância a falhas e tempo de recuperação, estão disponíveis, mediante solicitação especial, variantes de CPE especializadas e equipadas com uma pequena fonte interna de energia. Em casos de queda de energia, o CPE poderá enviar dados detalhados sobre o tipo de falha para o orquestrador. Isso dá aos administradores tempo para investigar a causa e resolver o problema muito mais rapidamente.

Estas são apenas algumas das inovações do Kaspersky SD-WAN. Outros recursos incluem a capacidade de configurar políticas de segurança para conexões com a porta de console do CPE, além do suporte a redes de grande escala com mais de 2 mil CPEs e balanceamento de carga entre múltiplos orquestradores. Para saber mais sobre como todos esses novos recursos aumentam o valor do SD-WAN para a sua organização, nossos especialistas estão disponíveis para oferecer uma demonstração personalizada.