---
title: "Tenable.IO: Conceitos, configuração e funcionamento"
tags: Tenable IO
---

# Tenable IO: Conceitos, configuração e funcionamento
      
  

## Sumário

[TOC]

# Apresentação

Neste documento consta detalhes sobre a configuração definida durante e após a instalação da solução Tenable.io. Por meio deste é possível acompanhar o passo-a-passo das configurações realizadas.

Algumas questões informativas como as boas práticas para o tratamento dos agentes e licenças são abordadas e as definições feitas pelo próprio cliente referente a forma de como são feitas as varreduras em seu ambiente.

Todas as funcionalidades foram passadas durante treinamento ministrado para o time Yandeh.

## O Escopo

O projeto consiste na implantação, configuração e customização da plataforma do Tenable.io + agentes locais e AWS. Inicialmente o projeto foi proposto a escanear até 200 ativos, conforme a primeira necessidade apresentada pela Yandeh. Verificamos, no entanto, que dada a estrutura das aplicações mantidas pelo cliente, este número é extrapolado, fazendo-se necessário ajuste do escopo, em alguns ambientes em cada varredura.

Todo o projeto foi baseado na proposta comercial e técnica enviada pela IBLISS e aceita pela Yandeh, por seus times técnico e de compras.

O escopo está sendo atendido pela solução da Tenable, o IO, que é uma solução em nuvem, ou seja, que trabalha com alta disponibilidade, da qual a responsabilidade pela disponibilidade e sustentação deste ambiente é da própria fabricante.

## Cronograma do Projeto

## Definição dos Recursos do Projeto

Abaixo temos a definição das equipes que participaram da fase de implantação da solução do Tenable.io durante o decorrer deste projeto. Aqui é informado quais foram os membros das equipes de ambos os lados (IBLISS e Yandeh).

| Responsabilidades | Profissionais da equipe de projeto |
| ----------------- | ---------------------------------- |
| Gerente do projeto (IBLISS) | Edgard Werter |
| Gerente de Serviços (IBLISS) | Reginaldo Sarraf |
| Gerente do projeto (Yandeh) | Paulo Nunes |
| Engenheiro de Segurança (IBLISS) | Evandro Santos |
| Engenheiro de Segurança (Yandeh) | João Messias Filho |

# Pré-requisitos do Projeto
Como principais diferenças do Nessus, não temos a necessidade de seleção de qual sensor utilizaremos, pois no momento da criação das varreduras podemos deixar de forma automática e a responsabilidade de seleção fica para o Tenable.io. Quanto aos agentes (sensores), devemos nos preocupar somente de atualizar a versão de sua aplicação, pois os plugins são atualizados automaticamente pela.

## Diagrama e Topologia de Rede
Atualmente todos os ativos que estão na lista de varredura, estão localizados em nuvem, especificamente na AWS. Na figura 1 é possível observar como está distribuído os sensores dentro do ambiente


*Figura 1: Diagrama do Tenable.io e Sensores*

# Implantação do Tenable IO

O Tenable.io funciona de forma similar ao Nessus, porém, facilitando todo o uso da ferramenta, extração de resultados e otimizando a performance dos escaneamentos no ambiente, pois ele fornece uma solução para gerenciamento de vulnerabilidades combinada com PCI-ASV, Dynamic Web Application Scanning e / ou Container Security.

Toda a base de escaneamento continua sendo realizada pelo Nessus, ou seja, todos os Nessus Professional presentes no ambiente passaram a se chamar Nessus Scanner, e para o ambiente AWS, em todas as suas subdivisões, foram utilizadas AMIs para a criação de Nessus Scanner. Com isso, temos uma console de gerenciamento central, que é o Tenable.io alocado em nuvem especificamente na nuvem da Amazon (AWS), controlando e gerenciando todo o processo de escaneamento do ambiente.

Com isso, saímos do conceito do Nessus com uma console para cada instância e partimos para o Tenable.io, onde ele gerencia todo e qualquer Nessus que tenha sido adicionado ao como sensor, assim no momento da criação de uma varredura é possível deixar no modo automático, permitindo que ele próprio identifique qual o melhor sensor, com base na sua localidade e disponibilidade.

O Tenable.io já conta com vários sensores em nuvem que ficam espalhados em várias regiões para permitir varreduras mais assertivas. Quanto aos sensores “on-premises” devemos somente mantê-los atualizados.

Após o entendimento do funcionamento, devemos nos preocupar somente de que precisamos ter as políticas, credenciais e arquivos de conformidade prontos antes de iniciar a configuração dos escaneamentos, já que apenas os selecionamos nas opções disponíveis.

## Sensores

Como já é descrito na sessão abaixo sobre planejamento e execução das varreduras os sensores que estão nos ativos da AWS permanecerão ligados por apenas dois dias na semana, sendo estes segunda-feira e terça-feira.

Fora este período estarão desligados sendo necessário ligá-los com antecedência de no mínimo trinta (30) minutos para que eles possam realizar a atualização dos plugins e até mesmo versão, em caso de varreduras pontuais.


*Figura 2: Sensores Nessus*

## Templates
Os escaneamentos criados estão utilizando os seguintes templates Advanced Scan e Internal PCI Network Scan como já foi apresentado detalhadamente da sessão técnica deste documento, até o momento da criação deste documento não houve alteração nenhuma.

Sendo que estes escaneamentos configurados estão distribuídos da seguinte forma:

* 13 scans com a configuração de template Advanced Network Scan:
* Alpe Gateway;
* Alpe PRD;
* Alpe Payone;
* Alpe Oruspay;
* Alpe Oruspay Windows;
* Inquest;
* iVendas 01;
* iVendas 02;
* iVendas 03;
* Yandeh PRD;
* Yandeh Interno;
* Yandeh Scan Links;
* YHub.
* 02 scans com a configuração de template Internal PCI Network Scan:
* Alpe Gateway (PCI Network Scan);
* Alpe Payone (PCI Network Scan).
* 02 scans com a configuração de template Internal PCI Quarterly External Scan:
* PCI Quarterly External Scan.
* 01 scan com a configuração de template Host Discovery:
* Alpe Oruspay Windows Discovery.

## Dashboards

O Dashboard definido foi o modelo padrão que já vem habilitado na plataforma, visto que sobre os dados extraídos, em cada varredura, é feita uma tratativa pela equipe interna da YANDEH, para adequação aos dashboards próprios que mantêm. porém é possível estar em etapa de ajustes pois ainda contém no nome o complemento que os define como cópia.

Logo no primeiro acesso já nos deparamos com a tela do Dashboard como
podemos observar na figura 3:


*Figura 3 : Sensores Nessus*

## Licenciamento

Na aba de licenciamento é possível acompanhar a quantidade limite de ativos para a licença contratada, a expiração da mesma e a região onde está a instancia do Tenable.io, a quantidade de licenças ativas podem oscilar dependendo do período de ativos escaneados, ativos que deixarem de ser analisados por mais de noventa (90) dias, deixam de consumir licenças.


*Figura 4: Licenciamento*

# Anexo I - Notas Finais

## Requerimentos Tenable IO

O Tenable é uma solução em nuvem por este motivo não há limitações físicas para ele, porém seus sensores devem sempre estar ativos e sincronizados. Lembrando que por melhores práticas os sensores não devem fazer varreduras atrás de Firewalls pois estes podem acabar bloqueando seu processo ou mesmo deixando muito lento.

## Credenciais no Tenable IO

Tenable.io oferece suporte às seguintes formas de autenticação de host

* [SNMPv3](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm#SNMPv3)
* [Secure Shell (SSH)](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm#SSH)
* [Windows](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm#Windows)

### SNMPv3

Use credenciais SNMPv3 para verificar sistemas remotos que usam um protocolo de gerenciamento de rede criptografado (incluindo dispositivos de rede). Tenable.io usa essas credenciais para verificar a auditoria de patch ou verificações de conformidade.

Clique SNMPv3 no Credenciais lista para definir as seguintes configurações:


### Secure Shell (SSH)

Use credenciais SSH para verificações baseadas em host em sistemas Unix e dispositivos de rede com suporte. O SSH criptografa os dados em trânsito para protegê-los de serem vistos por programas sniffer. Tenable.io usa essas credenciais para obter informações locais de sistemas Unix remotos para auditoria de patch ou verificações de conformidade.

Tenable.io pode usar programas baseados em protocolo Secure Shell (SSH) versão 2 (por exemplo, OpenSSH, Solaris SSH etc.).

Clique SSH no Credenciais lista para definir as configurações para os seguintes métodos de autenticação SSH:

* [Chave pública](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [Certificado](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [CyberArk Vault](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [HashiCorp Vault](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [Kerberos](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [Senha](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [Lieberman RED](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [Servidor secreto Thycotic](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [BeyondTrust](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)

Configurações de tipo de credencial em toda a digitalização.

**Nota**: *Os usuários não privilegiados com acesso local em sistemas Unix podem determinar problemas básicos de segurança, como níveis de patch ou entradas no “/etc /passwd”. Para obter informações mais abrangentes, como dados de configuração do sistema ou permissões de arquivo em todo o sistema, é necessária uma conta com privilégios de root.*

### Windows

Clique janelas no Credenciais lista para definir as configurações para os métodos de autenticação baseados no Windows descritos abaixo.

* [CyberArk Vault](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [HashiCorp Vault](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [Kerberos](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [Lieberman RED](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [LM Hash](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [NTLM Hash](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [Senha](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [Servidor secreto Thycotic](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [BeyondTrust](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)
* [Configurações de tipo de credencial em toda a digitalização](https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Scans/Host.htm)

#### Considerações sobre autenticação do Windows

Quanto aos métodos de autenticação:
* Tenable.io usa automaticamente a assinatura SMB se for exigida pelo servidor Windows remoto. A assinatura SMB é uma soma de verificação criptográfica aplicada a todo o tráfego SMB de e para um servidor Windows. Muitos administradores de sistema habilitam esse recurso em seus servidores para garantir que os usuários remotos sejam 100% autenticados e parte de um domínio. Além disso, certifique-se de aplicar uma política que exige o uso de senhas fortes que não podem ser facilmente quebradas por meio de ataques de dicionário de ferramentas como John The Ripper e L0phtCrack. Observe que tem havido muitos tipos diferentes de ataques contra a segurança do Windows para hashes ilícitos de computadores para reutilização em servidores de ataque. A assinatura SMB adiciona uma camada de segurança para evitar esses ataques man-in-the-middle.
* O protocolo SPNEGO (Simple and Protected Negotiate) fornece o recurso Single Sign On (SSO) de um cliente Windows para uma variedade de recursos protegidos por meio das credenciais de login do Windows dos usuários. Tenable.io oferece suporte ao uso de políticas e varreduras SPNEGO: Varreduras 54 de 151 com NTLMSSP com autenticação LMv2 ou criptografia Kerberos e RC4. A autenticação SPNEGO ocorre por meio da autenticação NTLM ou Kerberos; nada precisa ser definido na configuração de digitalização Tenable.io.
* Se um esquema de segurança estendido (como Kerberos ou SPNEGO) não for compatível ou falhar, Tenable.io tentará fazer o login via autenticação NTLMSSP / LMv2. Se isso falhar, o Tenable.io tenta fazer o login usando a autenticação NTLM.
* Tenable.io também oferece suporte ao uso de autenticação Kerberos em um domínio do Windows. Para configurar isso, o endereço IP do controlador de domínio Kerberos (na verdade, o endereço IP do Windows Active Directory Server) deve ser fornecido.

O Server Message Block (SMB) é um protocolo de compartilhamento de arquivos que permite aos computadores compartilhar informações na rede. Fornece essas informações ao Tenable.io permite que ele encontre informações locais de um host Windows remoto. Por exemplo, o uso de credenciais permite que Tenable.io determine se patches de segurança importantes foram aplicados.

Não é necessário modificar outros parâmetros SMB das configurações padrão. O campo de domínio SMB é opcional e Tenable.io é capaz de fazer logon com credenciais de domínio sem esse campo.

O nome de usuário, senha e domínio opcional referem-se a uma conta que a máquina de destino conhece. Por exemplo, com um nome de usuário “joesmith” e uma senha my4x4mpl3, um servidor Windows primeiro procura esse nome de usuário na lista de usuários do sistema local e, em seguida, determina se ele faz parte de um domínio.

Independentemente das credenciais usadas, Tenable.io sempre tenta fazer login em um servidor Windows com as seguintes combinações:
* Administrador sem senha;
* Um nome de usuário e senha aleatórios para testar contas de convidados;
* Nenhum nome de usuário ou senha para testar sessões nulas.

O nome de domínio real só é necessário se um nome de conta for diferente no domínio daquele do computador. É perfeitamente possível ter uma conta de administrador em um servidor Windows e dentro do domínio. Nesse caso, para fazer logon no servidor local, o nome de usuário do Administrador é usado com a senha dessa conta. Para fazer logon no domínio, o nome de usuário do Administrador também é usado, mas com a senha do domínio e o nome do domínio.

Quando várias contas SMB são configuradas, Tenable.io tenta fazer login com as credenciais fornecidas sequencialmente. Depois que Tenable.io consegue se autenticar com um conjunto de credenciais, ele verifica as credenciais subsequentes fornecidas, mas só as usa se privilégios administrativos forem concedidos quando contas anteriores fornecerem acesso de usuário.

Algumas versões do Windows permitem que você crie uma conta e designe a como administrador. Essas contas nem sempre são adequadas para realizar varreduras credenciadas. A Tenable recomenda que a conta administrativa original, denominada Administrador, seja usada para digitalização credenciada para garantir que o acesso total seja permitido. Em algumas versões do Windows, esta conta pode estar oculta. A conta de administrador real pode ser exibida executando um prompt do DOS com privilégios administrativos e digitando o seguinte comando:

C:\> net user administrator /active:yes

Se uma conta SMB for criada com privilégios de administrador limitados, Tenable.io pode fazer a varredura de vários domínios de maneira fácil e segura. A Tenable recomenda que os administradores de rede criem contas de domínio específicas para facilitar o teste. Tenable.io inclui uma variedade de verificações de segurança para Windows Vista, Windows 7, Windows 8, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 e Windows Server 2012 R2 que são mais precisas se uma conta de domínio for fornecida. Tenable.io tenta fazer várias verificações na maioria dos casos, se nenhuma conta for fornecida.

**Nota**: *O serviço Registro Remoto do Windows permite que computadores remotos com credenciais acessem o registro do computador que está sendo auditado. Se o serviço não estiver em execução, não será possível ler chaves e valores do registro, mesmo com credenciais completas. Este serviço deve ser iniciado para que uma varredura credenciada Tenable.io faça a auditoria completa de um sistema usando credenciais.*

*Varreduras credenciadas em sistemas Windows requerem que uma conta de nível de administrador completo seja usada. Vários boletins e atualizações de software da Microsoft tornaram a leitura do registro para determinar o nível do patch de software não confiável sem privilégios de administrador, mas nem todos eles. Os plug-ins Tenable.io verificam se as credenciais fornecidas têm acesso administrativo total para garantir que os plug-ins sejam executados corretamente. Por exemplo, é necessário acesso administrativo total para realizar a leitura direta do sistema de arquivos. Isso permite que Tenable.io se conecte a um computador e execute uma análise direta de arquivos para determinar o verdadeiro nível de patch dos sistemas sendo avaliados.*

# Recolhimento da Base de *Scan*

Em casos de abertura de chamado referente a algum processo de varredura com problema ou mesmo falha em identificar algum ativo é obrigatório o envio deste arquivo no momento da abertura do chamado.

Aqui vamos orientar passo a passo para obter a base do scan, primeiramente devemos navegar até o menu onde se localiza os Scans configurado.


*Figura 5: Selecionando o Scan*

Após localizar o scan que deseja recolher a base devera clicar nele para ser redirecionado para a outra página onde será encontrado a informação mais completa do Scan.


*Figuara 6: Abrindo o Scan*


*Figura 7: Baixando o Scan DB*

# Boas Práticas

## Limitaçoes do Projeto
Dentro do escopo solicitado a IBLISS, o projeto atende da seguinte forma, na RFQ foi solicitado o licenciamento para duzentos (200) ativos. Caso haja a necessidade de digitalizações de mais ativos é necessário realizar a aquisição mais licenças para evitar que seja utilizado mais licenças que estão disponíveis evitando assim possíveis alertas.

Em casos em que é consumida mais licenças que a quantidade contratada é necessária entrar em contato com a IBLISS para a tratativa, em nenhum momento quando ocorrer a excedência das licenças o sistema será de alguma forma bloqueado ou terá limitação de algum recurso.

Cada licença é liberada de forma automática após noventa (90) dias, desde que o ativo que a consome, não esteja sendo mais digitalizado neste período.

## Sensores Nessus
Todos os sensores são regularmente sincronizados com os servidores da Tenable a fim de verificar e atualizar seus plugins e versões, por padrão esse processo ocorre a cada uma hora, mas em casos que os sensores fiquem desligados é importante que antes de realizar a execução de escaneamentos seus respectivos sensores sejam ligados com certa antecedência para que eles possam ser atualizados, assim evitando que o processo de digitalização demore muito para finalizar ou mesmo não consiga se comunicar com os sensores.

## Grupos Alvos
Para casos em que o ambiente contém inúmeros ativos e somente alguns serão digitalizados é importante a criação dos Grupos Alvos (Target Groups) onde é possível apontar exatamente quais serão os alvos, assim também separando por localidade, sistema operacional ou mesmo tipo de ativo.

## Grupos de Exclusão
Após realizar a primeira varredura em seu ambiente já é possível identificar quais serão os alvos que serão digitalizados para a identificação de vulnerabilidades ou conformidades, caso nesse ambiente haja ativos que não deveram ser escaneados em hipótese nenhuma ou mesmo ficarão fora do processo em determinados períodos, para isso é de extrema importância que seja utilizado estes grupos. Assim evitando o consumo de licenças de forma equivoca.