Capacidades

Infrastructure Defense

Postura de segurança da sua infraestrutura. O agente Sentinel Host inventaria cada máquina e o Sentinel Probe executa scans nas redes ao redor delas, a nuvem correlaciona vulnerabilidades e configurações incorretas, o Viking Exposure Score as prioriza e o Resolve executa as correções aprovadas com uma redução de risco medida.

O WASViking^® Infrastructure Defense é a postura de segurança dos servidores que sustentam o seu negócio, em um só lugar: o que você tem, onde está vulnerável, quais correções importam mais e quanto risco cada correção executada realmente removeu. Ele trabalha com fatos que um agente leve coleta em cada host e nunca termina em "N vulnerabilidades encontradas"; o ciclo só se fecha quando um inventário posterior prova que o risco caiu.

Como funciona

Um agente pequeno, o WASViking Sentinel Host, roda em cada servidor registrado e reporta um inventário de postura de segurança via TLS mútuo: sistema operacional e kernel, pacotes instalados, serviços em execução e portas em escuta, atualizações pendentes e configurações de segurança, como o estado do firewall e as opções de hardening do SSH. O inventário de ativos também traz os dados da máquina que um operador espera encontrar em um registro de ativo: nomes (FQDN, hostname DNS e, no Windows, o nome NetBIOS), endereços IPv4 e IPv6, fabricante e modelo, processador e memória total, volumes fixos com espaço livre e os nomes das contas locais conforme o sistema operacional os reporta. Ele lê apenas a postura; nunca abre arquivos ou conteúdo de usuários, e os nomes de conta são coletados sem nenhum dado de perfil nem atividade por usuário.

Todo inventário é correlacionado na nuvem da WASViking:

Os pacotes instalados são comparados com o banco de dados de vulnerabilidades OSV, qualificados pela release exata da distribuição, de modo que um host com patch aplicado nunca é sinalizado pelo bug de outra branch. As atualizações do macOS vêm das releases de segurança publicadas, e os aplicativos de terceiros no Windows vêm do inventário do gerenciador de pacotes. O Amazon Linux, que o OSV não cobre, é comparado com os advisories de segurança do próprio fornecedor (ALAS), com a mesma comparação por pacote e qualificada pela release, para Amazon Linux 2023 e 2.
Os hosts Windows são avaliados pela revisão do build do sistema operacional. Toda correção de segurança que a Microsoft publicou em uma atualização cumulativa que o host ainda não alcançou é uma vulnerabilidade aberta, identificada com o KB e o build que a fecham. A revisão é o sinal autoritativo, então uma atualização que está instalada mas ainda aguarda uma reinicialização não conta como aplicada, e a lista de pendências do serviço de atualização mostra qual cumulativa fecha o quê.
Cada vulnerabilidade traz a sua severidade CVSS, a sua probabilidade de exploração EPSS e a indicação de presença no catálogo CISA Known Exploited Vulnerabilities.
Todo número de "what changed" (o que mudou) é uma porta, nunca um beco sem saída. Os chips do Command Center (achados novos e corrigidos nas últimas 24 horas) e os blocos de status da página Vulnerabilities abrem as detecções exatas por trás da contagem: host, pacote, versões instalada e corrigida, e o momento em que cada uma foi vista pela primeira vez ou comprovadamente fechada. Quando um host registrado no mesmo período responde por parte dos achados novos, a lista informa isso, porque um primeiro inventário reporta todo achado existente como novo. A exportação CSV segue o mesmo filtro.
As atualizações de segurança pendentes viram contexto de "missing patch" (patch ausente): quais vulnerabilidades abertas uma correção publicada fecharia.
Um sistema operacional ou um produto de software monitorado que passou do fim de suporte do fornecedor é sinalizado a partir de dados de ciclo de vida publicados, com a data no rótulo, porque nenhum patch virá para ele.
Um catálogo de configuração alinhado às seções dos benchmarks CIS avalia as configurações coletadas e pontua cada host com um percentual de conformidade, com um mapeamento PCI DSS dos mesmos resultados. Cada controle registra o valor esperado ao lado do que o host reportou, de modo que uma falha se explica sozinha. O catálogo cobre proteção de credenciais e movimento lateral no Windows (SMBv1, Network Level Authentication do Remote Desktop, proteção da LSA, WDigest, LAPS, LLMNR, assinatura SMB, nível de NTLM, UAC, WinRM, a política de auditoria avançada e o Microsoft Defender), hardening de kernel e de acesso no Linux (SELinux ou AppArmor, ASLR, parâmetros de rede do kernel, auditd, logs persistentes, sincronização de horário, a configuração efetiva do sshd, sudo, contas locais, permissões de arquivos do sistema, assinaturas de repositórios), e o login, a conta root, o modo furtivo (stealth mode) e as atualizações de dados de segurança no macOS. A postura da plataforma é coletada em paralelo: criptografia de disco, estado do Secure Boot e do TPM no Windows, System Integrity Protection, Gatekeeper e registro em MDM no macOS. O agente reporta apenas fatos; um fato que um agente mais antigo não reporta é não aplicável, nunca uma falha.
Cada política de host seleciona o perfil ao qual os seus hosts são submetidos: a baseline WASViking, ou o CIS Level 1 com os limites mais rígidos e os controles adicionais do Level 1. Os limites (tamanho de senha, bloqueio por inatividade, bloqueio de conta) podem ser ajustados por política, e verificações individuais podem ser desligadas. Um aprovador pode aceitar o risco de um controle em falha por um motivo declarado até uma data: o controle então conta como aprovado com exceção, permanece visível como risco aceito e volta à lista de abertos quando a exceção expira. Configurações incorretas abertas, críticas e altas, adicionam um fator limitado ao Viking Exposure Score.
Alguns achados trazem uma ação de hardening que o operador pode enviar ao host com a permissão Remediate: desativar o SMBv1, exigir Network Level Authentication, desligar o LLMNR, aplicar o hardening de rede do kernel. O agente aplica a mudança documentada, reporta um inventário novo, e o achado fecha com base nessa evidência.
A própria descoberta de superfície de ataque da plataforma comprova a exposição à internet: quando um ativo público descoberto resolve para um endereço atribuído ao host, o indicador de exposição acende com a prova identificada, e uma decisão manual da sua equipe sempre prevalece sobre a automação. A telemetria de borda adiciona um fator de ataque ativo quando tráfego bloqueado de nível de ataque atingiu, nos últimos sete dias, um hostname que o servidor atende; o fator decai sozinho quando o tráfego para.
A mesma correlação roda no sentido inverso. Todo ativo voltado para a internet que você possui no Attack Surface é comparado com os seus hosts registrados e rotulado com um estado de gerenciamento: Fully managed (totalmente gerenciado), Partially managed (parcialmente gerenciado), Unmanaged (não gerenciado) ou Unknown (desconhecido). O Command Center diz em uma frase quantos ativos expostos externamente ainda não estão protegidos, a aba Coverage lista esses ativos com o próximo passo para cada um (instalar o agente, adicionar credenciais ao probe, vincular o ativo ao host atrás de uma CDN ou de um WAF), e o inventário de ativos mostra o mesmo veredito pelo outro lado. Ativos que ainda aguardam triagem no Discovery nunca são contados como desprotegidos. O passo a passo está em Coloque seus ativos voltados para a internet sob gerenciamento.

A visão de rede: Sentinel Probes

O agente mostra o interior de cada máquina em que você consegue instalá-lo. Um Sentinel Probe mostra o restante da rede. Ele é um appliance virtual de scanner: um programa leve em uma única máquina de um segmento descobre todo dispositivo alcançável nas redes que você autoriza, identifica os serviços e as versões que eles expõem e os reporta à mesma nuvem, para correlação e para o mesmo Viking Exposure Score. Nada é instalado nos dispositivos que ele analisa e, como o agente, ele só faz conexões de saída via TLS mútuo.

É isso que cobre o que nunca vai rodar um agente, como um switch gerenciado, uma impressora, um appliance de banco de dados ou um terminal de pagamento, e é assim que o módulo produz o scan interno de vulnerabilidades que o PCI DSS pede. As redes que você declara são analisadas em uma cadência definida por você, cada execução é mantida como evidência datada (requisito 11.3.1), uma passagem autenticada via SSH ou WinRM olha além da superfície onde um sistema aceita credenciais (requisito 11.3.1.2), e um Scan now de um clique registra uma execução fora do ciclo após uma mudança (requisito 11.3.1.3). Um dispositivo que o probe encontra e que não tem agente aparece no seu inventário como Unmanaged, então você sempre sabe o que gerencia e o que apenas existe na rede. O guia de configuração dos Sentinel Probes mostra como instalar um, autorizar as suas redes e ler os resultados.

O Viking Exposure Score

Cada host recebe um Viking Exposure Score de 0 a 100. A pior vulnerabilidade aberta define a base; evidências de exploração (KEV, EPSS), exposição à internet comprovada, tráfego de ataque ativo visto na borda, estado de fim de vida, criticidade para o negócio e ambiente ajustam o valor. A pontuação nunca é uma caixa-preta: toda tela mostra os fatores e os pontos exatos por trás do número, então "por que isto é crítico" sempre tem uma resposta concreta.

Resolve: remediação com prova

O WASViking Resolve transforma as prioridades em trabalho sob o seu controle:

As ações recomendadas agrupam as atualizações de segurança pendentes de cada host, ordenadas pela redução de pontuação que se espera delas.
Agendar uma ação a congela como um job com a lista exata de pacotes, de modo que o aprovador autoriza uma mudança concreta. Abra Review e desmarque as atualizações que você quer deixar para depois: o job só toca no que permanece marcado, e as vulnerabilidades fechadas e a pontuação esperada são recalculadas para essa seleção. As atualizações deixadas de fora continuam recomendadas para o próximo job.
Uma pessoa com a permissão Remediate aprova o job, opcionalmente dentro de uma janela de manutenção definida pela política de host. A implantação automática e a reinicialização automática vêm desativadas por padrão.
O agente executa pré-verificações, aplica as atualizações pelo mecanismo nativo de cada plataforma (o gerenciador de pacotes do sistema no Linux, o serviço de atualização no Windows, as atualizações de software no macOS) e reporta o resultado por item. Aplicativos de terceiros no Windows (navegadores, leitores, runtimes) têm a sua própria ação, "Upgrade third-party applications" (atualizar aplicativos de terceiros), alimentada pelos upgrades que o canal winget oferece naquele host. Mesmo congelamento, mesma aprovação e mesmo resultado por item; o agente atualiza cada aplicativo pelo seu id de canal e nunca algo que o job não nomeou. Para os aplicativos que o motor de detecção mapeia (navegadores, clientes de e-mail, editores, runtimes e outros softwares comuns de desktop), a versão instalada é comparada com a NVD por produto e versão, então a ação mostra as vulnerabilidades que o upgrade fecha e a pontuação esperada, como faz uma atualização de segurança; um aplicativo sem mapeamento mantém o rótulo "app currency" (atualidade do aplicativo), e o job o mantém na versão atual do fornecedor. O veredito é o próximo inventário deixar de oferecer o upgrade, com os achados que ele fechou.
O próximo inventário é o veredito: o job só se conclui quando a reavaliação mostra quais vulnerabilidades fecharam e quanto a pontuação caiu. Os números de antes e depois são medidos, nunca estimados, e quando uma reinicialização ainda está pendente o job informa isso em vez de declarar vitória cedo demais.

Uma mudança por vez. Logo antes de instalar, o agente lê os sinais de reinicialização do próprio host (a servicing stack, o Windows Update e as renomeações de arquivo pendentes no Windows; o marcador reboot-required ou o needs-restarting no Linux). Quando uma reinicialização de uma mudança anterior ainda está pendente, o job fica retido em vez de empilhar uma segunda mudança sobre uma inacabada: a tela Resolve mostra "Held, restart pending" (retido, reinicialização pendente) com o motivo, o ativo mostra desde quando e depois de qual mudança a reinicialização é devida, e o job é retomado sozinho no momento em que o host reporta a reinicialização concluída. A política decide a exceção: reiniciar o host primeiro (somente quando o aprovador também concedeu a reinicialização) ou instalar mesmo assim no Linux e no macOS. O Windows sempre espera, já que o Windows Update recusa instalações com uma reinicialização pendente. Uma ação "Restart host" (reiniciar o host) no ativo e na tela Agents encerra a espera com um clique, para pessoas com a permissão Remediate, e um job que ainda espera depois de um dia gera um alerta nos seus canais.

Uma reinicialização também pode ser agendada como um job próprio. A tela Resolve recomenda "Restart host to finish pending changes" (reiniciar o host para concluir mudanças pendentes) para todo host com uma reinicialização pendente, e o relatório "Hosts waiting for a restart" (hosts aguardando reinicialização) lista esses hosts do mais antigo para o mais recente, com a causa, a função do host, as sessões conectadas e a política aplicável, com uma exportação CSV e uma ação "Schedule restart for all" (agendar reinicialização para todos). Um job de reinicialização segue o mesmo contrato de qualquer mudança: aprovação conforme a política, a janela de manutenção e um veredito do próximo inventário, que comprova a reinicialização pelo horário de boot que o host reporta. O agente distingue servidores de estações de trabalho por conta própria. Um servidor reinicia após a contagem regressiva que a política define; uma estação de trabalho com uma pessoa conectada recebe antes uma pergunta e pode adiar quantas vezes a política permitir, e depois disso a contagem regressiva roda sem pergunta. Um host cuja reinicialização permanece pendente por sete dias gera o seu próprio alerta, com ou sem job.

Uma mudança que deu problema pode ser desfeita com a mesma disciplina. Um job de atualização de segurança concluído em um host Linux ou Windows oferece "Roll back this change" (reverter esta mudança): um job de rollback para os mesmos pacotes, cada um devolvido à versão exata que tinha antes, com um motivo obrigatório, o plano de reversão herdado, e as regras de aprovação, janela e reinicialização de qualquer outra mudança. O Linux faz o downgrade pelo gerenciador de pacotes e nunca toca no kernel; o Windows remove cada atualização pelo seu KB por meio do Windows Update e reporta as que a plataforma não permite remover; o macOS não tem caminho de desinstalação, e a tela informa isso. A reavaliação mede o resultado com honestidade, "VES 70 to 88, 3 of 3 packages returned, 17 vulnerabilities open again" (VES de 70 para 88, 3 de 3 pacotes devolvidos, 17 vulnerabilidades abertas de novo), e as atualizações devolvidas ficam retidas fora das recomendações pelos dias que o job pediu, visíveis no host e liberadas antes do prazo com um clique. Veja Reverter uma mudança que deu problema.

A governança de aprovação decide quem autoriza, por ambiente. Cada host traz um ambiente (produção, staging, desenvolvimento ou outro), e a tela Approval Governance define uma regra para cada um: seguir a política de host, aprovar automaticamente, deixar uma pessoa aprovar (inclusive o solicitante) ou exigir uma aprovação formal. Uma regra formal diz de quantas aprovações um job precisa e, opcionalmente, quem pode dá-las, por nome ou por papel; a pessoa que agendou o job nunca conta. Toda decisão é registrada com quem decidiu, quando, o motivo declarado e a referência da mudança, e os registros de aprovação são exportados como CSV: a evidência que uma auditoria de controle de mudanças pede. Uma regra de produção também pode exigir que os mesmos pacotes tenham sido concluídos em staging ou em desenvolvimento dentro de uma janela antes que a produção os aceite; um job que chega sem teste informa isso, e um aprovador precisa dispensar a exigência de propósito. Aprovações que esperam além da janela definida na regra são canceladas, aprovações formais em espera são anunciadas aos seus canais de alerta e aos aprovadores por e-mail, e o solicitante fica sabendo da decisão. Quando a regra permite, uma aprovação de emergência executa o job sem o quórum, com um motivo declarado; todo aprovador é notificado e o job permanece sinalizado até que outro aprovador o revise. Quando a regra nomeia os seus aprovadores, o caminho de emergência também pertence a essa lista. A pessoa que agenda uma mudança pode declarar por que ela é necessária e como é desfeita, e uma regra pode recusar uma mudança agendada sem esse plano de reversão; ambos ficam no registro de aprovação e na exportação. Um job responde ao ambiente em que foi criado: mover um host para um ambiente menos protegido depois disso não muda nada para os jobs que já estão esperando, e a própria movimentação exige a permissão Approve, é registrada com o antes e o depois e gera um alerta nos seus canais.

As políticas decidem até onde a plataforma pode ir em cada grupo de hosts: o que é avaliado, se os jobs precisam de aprovação manual onde a governança segue a política, e quando as mudanças são permitidas. Toda ação vai para a trilha de auditoria, e o resultado do job de patch pode notificar os seus canais de Slack, Teams, e-mail ou webhook.

A proteção de desempenho e de recursos faz parte da mesma política. Ela declara quanto de um host o agente pode usar e quando ele deve ceder espaço: uma fração da CPU da máquina (um teto rígido por meio do control group do systemd no Linux e de um job object no Windows, uma prioridade de escalonamento no macOS), a cadência de inventário e de check-in, prioridade de escalonamento reduzida para o agente e para todo subprocesso que ele cria, e uma janela diária de atividade reduzida no horário local do próprio host. Três presets cobrem os casos usuais: Conservative para produção crítica, Balanced para o parque em geral, Performance para desenvolvimento e teste; Custom expõe todos os números. Além do limite estático, o agente observa o host antes de toda avaliação agendada e antes de todo job de patch. Um host acima dos limites de CPU ou de memória da política, ou sob carga crítica, é deixado em paz: a avaliação espera e olha de novo a cada dez minutos, até o máximo da política, e então roda mesmo assim em prioridade reduzida, para que a cobertura nunca se interrompa em silêncio; um job de patch volta para a nuvem como adiado, é oferecido de novo um quarto de hora depois e falha de forma visível, com os números na nota, se o host não se acalmar dentro da espera máxima. A página de cada ativo mostra o que o seu agente reporta: a revisão do perfil que ele aplica, como a plataforma o impõe, a última amostra de carga e qualquer trabalho em espera. Agentes a partir da release 0.1.34 aplicam o perfil; agentes mais antigos seguem apenas a cadência de inventário dele.

A higiene do parque mantém a lista de agentes fiel à realidade sem que ninguém precise arrumá-la. A franquia de hosts monitorados conta ativos que reportaram, nunca tentativas de registro. Um instalador que não consegue alcançar a nuvem para antes de registrar e nomeia o produto que está no caminho; um registro que foi criado mas nunca enviou o seu primeiro inventário gera um único alerta com a verificação a executar e as exclusões a aplicar; um token nunca usado expira; e quando uma máquina finalmente reporta, os registros anteriores do mesmo hostname que nunca foram concluídos são aposentados sozinhos. A tela Sentinel Hosts sinaliza o que precisa de atenção (nunca reportou, token nunca usado, hostname duplicado, em silêncio há uma semana), oferece a remoção em um clique dos registros incompletos de um hostname e permite definir as janelas de limpeza: por quanto tempo um host em silêncio é mantido, por quanto tempo um token vive sem uso e em quanto tempo a falta do primeiro inventário é anunciada.

Relatórios

A tela Overview responde à pergunta de dez segundos: risco geral da infraestrutura, os números do parque e os principais riscos com os seus motivos. Um relatório em PDF com identidade visual exporta a mesma história para os stakeholders: postura do parque, redução de risco verificada, principais vulnerabilidades, configurações incorretas e conformidade por host.

Configuração

O Infrastructure Defense é um módulo add-on ativado por organização. Depois de ativado, abra Infrastructure Defense → Sentinel Hosts no portal. Para um único servidor, registre um host para obter as credenciais de uso único dele e execute os dois comandos mostrados no cartão de registro (register, depois run). Para um parque, abra a aba Activation keys, gere uma chave reutilizável (com limite de agentes e expiração opcionais), escolha a plataforma na página de instalação dela, baixe o pacote do agente para Windows, Linux ou macOS e execute o comando de instalação mostrado ali: ele carrega a chave, registra o host e inicia o serviço em um único passo. Parques Windows podem usar o pacote MSI padrão com as ferramentas de implantação em massa que já utilizam, e os agentes registrados se mantêm atualizados com a autoatualização em um clique a partir do console. Nos dois casos, o host aparece na tela Assets com o seu primeiro inventário em minutos, e a pontuação dele vem depois da primeira avaliação. Para o fluxo completo com capturas de tela, da primeira chave de ativação ao primeiro job de patch verificado, siga o guia de configuração passo a passo. Para adicionar a visão de rede, execute um Sentinel Probe em cada segmento com o guia de configuração dos Sentinel Probes. O checklist de ativação de módulos cobre como ligar o módulo.