[PT-BR] Application Control Deep Dive: Appscan, Re...

jorgeluiznim

Artigo 15 da série Harmony Endpoint Deep Dives · Nota sobre a gestão: o Harmony Endpoint é gerenciado na nuvem pelo Infinity Portal (Web Management). O Application Control fica em Policy > Access & Compliance > Application Control, e os apps em Manage > Manage Applications.

Quase todo projeto de allow-listing morre do mesmo jeito. Alguém bloqueia aplicações pelo nome, o atacante renomeia malware.exe para notepad.exe e o controle vira teatro. O Application Control não entra nesse jogo: ele identifica cada programa por um checksum infalsificável, e não pelo nome. Binário renomeado não engana ninguém. O resto do blade só merece confiança por causa dessa decisão de projeto, então tudo abaixo parte dela.

RESUMO
A identidade é por checksum, não por nome. O inventário nasce do scan de uma máquina de referência limpa com o Appscan. Cinco estados de permissão decidem entre allow, block e terminate. O Reputation Service aperta os seus padrões de "unidentified", mas nunca passa por cima de uma regra explícita. O Terminate mata o processo, não só a porta. E o Developer Protection impede que segredos cheguem ao Git.

O que você precisa antes de começar: um reference computer livre de malware por imagem padrão (para o Appscan) e o básico da política de Access & Compliance (Artigo 1). Só isso.

Duas coisas que o tornam confiável

O Application Control restringe o acesso à rede das aplicações que você escolher, e pode dar allow, block ou terminate em um processo, inclusive matá-lo no momento em que ele tenta alcançar a rede. Dois mecanismos sustentam isso:

Identidade por checksum: cada aplicação e versão tem um checksum único e infalsificável, então um programa malicioso não consegue se passar por um inofensivo.
Reputation Service (o antigo Program Advisor): serviço online que classifica apps como approved ou not approved, com base nos especialistas da Check Point e no hash do certificado assinado do app.

Montando o inventário com o Appscan

Você não digita nomes de aplicação. Você escaneia um reference computer, uma imagem controlada e livre de malware com os apps típicos da organização, uma por build padrão. O fluxo é este:

O Appscan é uma ferramenta de CLI. No console cloud você baixa em Policy > Access & Compliance > Manage > Manage Applications > Download Appscan (também na sk108536) e roda no dispositivo de referência. Sintaxe básica:

Appscan [/o<filename> /s<targetdirectory> /x<extensionstring> /e /a /p /verbose /warnings /?]

/o define o arquivo de saída (padrão scanfile.xml), e cada aplicação e versão recebe o seu checksum. Um cuidado antes de importar o XML: remova os caracteres especiais (símbolos de trademark e copyright), ou a importação pode falhar.

Os cinco estados de permissão

Todo app do inventário está em um destes cinco estados:

Permissão	Significado
Unidentified (Allow)	Importado, não classificado, permitido porque o padrão é "Allow unidentified applications"
Unidentified (Block)	Importado, não classificado, bloqueado porque o padrão é "Block unidentified applications"
Allow	Permitido explicitamente pelo admin, sobrescreve o Reputation Service
Block	Bloqueado explicitamente pelo admin, sobrescreve o Reputation Service
Terminate	O app é terminado ao tentar alcançar a rede, ou imediatamente ao executar

A Allowed Applications List é Unidentified (Allow) mais Allow, e os usuários só podem usar esses.
A Blocked Applications List é Unidentified (Block) mais Block mais Terminated.
A seção Versions mostra o número, o Hash (signer) e a data Created On de cada versão, então dá para permitir uma versão de um programa e bloquear outra.

Como o Reputation Service inclina os padrões

Esta é a parte que vale acertar. Com o Reputation Service ligado, o client combina a recomendação dele com a permissão da sua política:

Reputation	Setting da política	Decisão do client
Approved	Unidentified (Allow/Block) ou Allow	Allow
Approved	Block	Block
Not Approved	Unidentified (Allow/Block) ou Block	Block
Not Approved	Allow	Allow

Lendo a tabela com calma, saem duas regras:

Um app em Unidentified (Allow) que o Reputation marca como Not Approved acaba bloqueado. A reputação aperta o seu padrão frouxo, e é isso que você quer.
Um Allow ou Block explícito sempre vence. A reputação nunca derruba uma decisão que você tomou de propósito.

Minha opinião: ligue. Você ganha o "bloqueie os desconhecidos ruins" sem classificar à mão cada ferramenta da empresa, e as suas regras deliberadas continuam mandando. Uma nota da era cloud: o Reputation Service é alcançado pela nuvem da Check Point, então o antigo ajuste de proxy no local.properties do on-premises não se aplica. Só garanta que os clients consigam sair para os endpoints de Reputation e ThreatCloud.

Terminate: matando o processo, não só a porta

Configurado em Access & Compliance > Application Control, em dois modos:

Terminate on connection: o app é morto quando tenta alcançar a rede. O que nunca toca a rede (Notepad, Calculator) fica em paz.
Terminate on execution: selecionado por padrão, o app é morto no momento em que executa.

Nota: o Terminate exige que os clients e a política de Compliance estejam configurados para permiti-lo (veja a sk141692). É aqui que o Artigo 14 e este se encontram.

Controle de WSL

O Windows Subsystem for Linux roda binários Linux sob o Windows, uma superfície real e muitas vezes ignorada. O Application Control pode Disable WSL Traffic ou Enable WSL Traffic direto na regra. Se o WSL ainda não entrou no seu allow-listing, este é um bom momento.

Developer Protection: barrando segredos no `git commit`

Este é o destaque moderno, e o recurso que pouca gente espera achar num produto de endpoint. O Developer Protection impede que desenvolvedores vazem dados sensíveis (chaves RSA, senhas, access tokens) pelo Git, e sinaliza dependências externas vulneráveis (por exemplo em AWS Lambda). Ele atua bem no commit:

Modo	Comportamento
Disabled	Padrão
Detect	Vazamento detectado, registrado em log, desenvolvedor notificado, mas o commit prossegue
Prevent	Vazamento detectado, registrado em log, e o commit é bloqueado. O desenvolvedor pode fazer override (com ou sem justificativa), e a notificação ainda sugere a correção: adicionar ao `.gitignore`, subir a versão no `package.json`

Num parque de desenvolvedores eu rodaria primeiro em Detect para medir o ruído e depois passaria para Prevent. Barrar uma credencial no commit sai bem mais barato do que rotacioná-la depois que ela chegou a um repositório público.

Como eu faria o rollout

Monte o inventário do Appscan a partir de uma imagem de referência limpa por build padrão. Uma referência comprometida envenena o whitelist inteiro, então esta não é a etapa para ter pressa.
Habilite o Reputation Service para que os apps unidentified "Not Approved" sejam bloqueados sozinhos, enquanto as suas regras explícitas de Allow/Block continuam valendo.
Para allow-listing de verdade, deixe o padrão em Block Unidentified Applications, mas faça um piloto antes. Virar essa chave na empresa inteira no primeiro dia bloqueia ferramenta legítima e enche o helpdesk de chamado.
Coloque o Developer Protection em Prevent nas máquinas de desenvolvedor, depois de um período curto em Detect para medir o impacto.

Erros para evitar

Erro	Impacto	Correção
Escanear um reference computer que não está limpo	Malware entra no whitelist	Use uma imagem controlada e livre de malware
Importar um XML com caracteres de trademark/copyright	A importação falha	Remova os caracteres especiais antes
Esperar que o Reputation passe por cima de uma regra explícita	Não passa, o Allow/Block do admin vence	Use regras explícitas de propósito
Ativar Block Unidentified sem piloto	Ferramentas legítimas bloqueadas, enxurrada de chamados	Faça piloto e classifique antes os apps comuns
Achar que o Terminate para o Notepad	Apps que não usam rede não são terminados	O Terminate mira apps que tocam a rede, ou use Terminate on execution

Um caso de troubleshooting

Sintoma: um app marcado como "Unidentified (Allow)" está sendo bloqueado.
Por quê: o Reputation Service o classificou como Not Approved, o que aperta o padrão "Unidentified (Allow)" para Block.
Correção: se você confia no app, coloque-o em Allow explícito (isso sobrescreve a reputação) e confira se o Hash da versão é o que você quer permitir, já que as permissões são por versão.

Respostas rápidas

Quem vence, a minha regra ou a reputação? O seu Allow/Block explícito, sempre. A reputação só decide para apps unidentified.
Block ou Terminate? O Block nega o acesso à rede; o Terminate encerra o processo (ao acessar a rede, ou imediatamente ao executar).
Posso permitir uma versão e bloquear outra? Sim, as permissões são por versão (cada uma tem o seu número e Hash).

Esse é o Application Control de ponta a ponta: identidade por checksum, inventário limpo, reputação apertando os padrões e Developer Protection pegando segredos antes que saiam do notebook. Como você faz allow-listing hoje, com Block Unidentified estrito ou com apoio do Reputation Service? Tenho curiosidade de saber como outros times defendem o piloto internamente.

Relacionados e fontes

Compliance Deep Dive, Artigo 14 (o Terminate depende do Compliance configurado)
Check Point Harmony Endpoint Administration Guide (cloud / Infinity Portal), Access and Compliance Policy > Application Control (Manage Applications, Appscan, identidade por checksum, estados de permissão, Reputation Service, Terminate, WSL Traffic, Developer Protection)
sk108536 (Appscan) e sk141692 (configuração do Terminate)

Harmony Endpoint com gestão cloud (Infinity Portal / Web Management), clients Windows.

Are you a member of CheckMates?