Resumo CompTIA Security+ Study Guide: Capítulo 5

Domain 1.0 – Threats, Attacks, and Vulnerabilities
1.6 Explain the security concerns associated with various types of vunlerabilities
1.7 Summarize the techniques used in security assessments
Domain 4.0 – Operations and Incident Response
4.1 Given a scenario, use the appropriate tool to assess organizational security

Vulnerability Management
O ambiente técnico de uma organização é complexo, com servidores, endpoints, dispositivos de rede, … Inevitavelmente eles terão vulnerabilidades.

Vulnerability Management consiste em identificar, priorizar e remediar vulnerabilidades no ambiente. E para isso são utilizadas ferramentas de scans de vulnerabilidade.

Identifying Scan Targets
Após decidir fazer um scan de vulnerabilidade, é necessário identificar quais sistemas serão escaneados.

Algumas perguntas podem ajudar a definir isso (o sistema é exposto para Internet? Que serviço é oferecido pelo sistema? O ambiente é de produção, teste, homologação?).

Também são usadas ferramentas para identificar sistemas na rede, criando um inventário. E os administradores podem complementar as informações, ajudando a identificar sistemas críticos/não críticos.

Scan Frequency
Ferramentas de scan permitem o agendamento automatizado, atendendo as necessidades do ambiente, compliance e necessidades do negócio.

O scan pode automaticamente gerar alertas de novas vulnerabilidades, além enviar relatórios por e-mail.

Fatores que influenciam a frequência do scan:

• Apetite a risco: Quanto a organização está disposta a correr de risco? Menos tolerantes devem rodar o scan com mais frequência.
• Requisitos regulatórios: PCI DSS (Payment Card Industry Data Security Standard) e FISMA (Federal Information Security Management Act) indicam a frequência mínima para o scan. A política da organização também pode definir isso.
• Limitações técnicas: Podem limitar a frequência do scan, definindo quantidade máxima de ativos escaneados por dia.
• Limitações do negócio: Podem impedir scan intensivos durante o horário de produção, para evitar o risco de interromper algum processo crítico.
• Limitações de licenciamento: A quantidade de banda necessária ou o número de scan/endpoints, pode ser limitado de acordo com a licença disponível.

Scan Sensitivity Levels

Normalmente um administrador pode começar utilizando um template pré-definido, fornecido pela solução de scan. E posteriormente ir customizando (e também salvando em templates para facilitar) para atingir os objetivos desejados.

Também é possível utilizar plugins, melhorando a eficiência do scan. Da mesma forma, desativar checagens desnecessárias é uma boa prática.

Supplementing Network Scans

Scans de rede fazem os testes “a distância”, e apesar de dar uma visão real do que um atacante veria (também via rede), pode ser limitado por conta de firewalls, IPS e outros sistemas de segurança.

Também podem ocorrer falsos positivos, por conta destes filtros na rede.

Para evitar essa situação é possível fazer scan com credenciais, permitindo o scan realmente acessar o servidor e conseguir as informações adequadamente. Desta forma é possível detectar se uma atualização específica está instalada (enquanto que via rede, vai ser identificado apenas a versão do SO).

Outra opção é utilizar um agente, instalando nos servidores desejados. Neste caso o scan acontece localmente, e então os status são enviados para a plataforma de gerência.

Scan Perspective

É possível fazer scan a partir de vários pontos da rede, e isso traz uma perspectiva diferente sobre as vulnerabilidades. Um scan a partir da Internet vai mostrar o que um atacante externo enxerga, enquanto um scan de dentro da rede mostrará vulnerabilidades que seriam encontradas por um atacante interno.

Já um scan dentro do data center traz informações mais precisas, normalmente.

PCI DSS requer scan interno e externo, e as plataformas de gerência de vulnerabilidade podem agregar as informações de diferentes scans, provendo uma visão consolidada dos resultados.

Scanner Maintanance

As plataformas de gerência de vulnerabilidade não estão imunes às vulnerabilidades, e devem ser atualizadas e também verificadas.

Além disso, novas vulnerabilidades são encontradas diariamente, então é importante manter os plugins atualizados (geralmente via feeds de atualização).

SCAP

O Security Content Automation Protocol (SCAP) é uma iniciativa da comunidade de segurança, e liderado pelo NIST (National Institute of Standards and Technology) para criar um padrão para comunicação de informações relacionadas a segurança, e inclui:

• Common Configuration Enumeration (CCE): Padrão de nomenclatura para discussão de problemas de configuração de sistemas.
• Common Platform Enumeration (CPE):  Padrão de nomenclatura para produtos e versões.
• Common Vulnerability and Exposures (CVE): Padrão de nomenclatura para descrição de falhas relacionadas a softwares.
• Common Vulnerability Scoring System (CVSS): Padrão para mensurar e descrever a severidade de falhas em softwares.
• Extensible Configuration Checklist Description (XCCDF): Padrão para check-list e relatórios de resultados com check-list.
• Open Vulnerability and Assessment Language (OVAL): Linguagem para especificar procedimentos de testes usados nos checklists.

Vulnerability Scanning Tools

Existem várias opções de ferramentas, que podem ser vistas abaixo.

• Infrastructure Vulnerability Scanning: Scan de rede, capaz de detectar dispositivos conectados à rede e identificar vulnerabilidades conhecidas. Tenable Nessus, Qualys, Rapid7 e OpenVAS (free) são opções de scanner de rede, e a organização deveria ter pelo menos um deles.
• Application Scanning: Normalmente usados como parte do processo de desenvolvimento de aplicações. Temos 3 técnicas:
  • Static Testing: O código é analisado sem ser executado, e apontamentos são feitos para o desenvolvedor.
  • Dynamic testing: Executa o código como parte do teste, testando todas as interfaces que são expostas aos usuários.
  • Interactive Testing: Combina os dois anteriores, analisando o código e as interfaces expostas.
• Web Application Scanning: Ferramentas especializadas em segurança para aplicações web. Testam SQL Injection, cross-site scripting (XSS) e cross site request forgery (CSRF), por exemplo. Niko é uma ferramenta popular deste tipo (open source), usada via CLI. Outra opção open source é o Arachni. Ferramentas pagas incluem Nessus, Qualys e Nexpose.

Reviewing and Interpreting Scan Reports

O relatório de scan de vulnerabilidade contém uma grande quantidade de informações, com detalhes das vulnerabilidades encontradas, como nome, severidade, descrição detalhada e solução para a vulnerabilidade, quando possível.

Também inclui o CVSS (Common Vulnerability Scoring System).

Understanding CVSS

O CVSS é um padrão para classificar a severidade da vulnerabilidade, e pode ser usado para priorizar as ações de correção.

Attack Vector Metric

Descreve como um atacante exploraria a vulnerabilidade, e é associado de acordo com:

• Physical (P): Tem contato físico com o dispositivo vulnerável (score 0,20).
• Local (L): Atacante deve ter acesso físico ou lógico ao sistema afetado (score 0,55).
• Adjacent Network (A): Atacante precisa de acesso a rede local onde está o dispositivo afetado (score 0,62).
• Network (N): O atacante pode explorar a vulnerabilidade remotamente, através da rede (score 0,85).

Attack Complexity Metric

Descreve a dificuldade de explorar uma vulnerabilidade, e é classificada pelos seguintes critérios:

• High (H): Explorar a vulnerabilidade requer condições “especiais”, que seriam difíceis de encontrar (score 0.44).
• Low (L): Vulnerabilidade mais facilmente explorada (score 0,77).

Privileges Required Metric

Descreve o tipo de conta de acesso que o atacante precisa para explorar a vulnerabilidade, e segue os critérios:

• High (H): Conta de nível administrativa para conduzir o ataque (score 0,270 ou 0,50 se o escopo é alterado).
• Low (L): Ataque requer conta com privilégios básicos (score 0,62 ou 0,68 se o escopo é alterado).
• None (N): Não é necessária autenticação para explorar a vulnerabilidade (score 0,85).

User Interaction Metric

Descreve se o ataque precisa de alguma interação de outro humano para ter sucesso. Classificado como:

• None (N): Exploração não precisa de ação de nenhum outro usuário além do atacante (score 0,85).
• Required (R): É necessária a interação de algum outro usuário para o ataque ter sucesso (score 0,62).

Confidentiality Metric

Descreve o tipo de exposição de informação que pode ocorrer se um atacante explorar com sucesso a vulnerabilidade. Classificado de acordo com os seguintes critérios:

• None (N): Não há impacto de confidencialidade (score 0,0).
• Low (L): Acesso a algumas informações é possível, mas o atacante não tem controle sobre que tipo de informação está comprometida (score 0,22).
• High (H): Toda informação do sistema é comprometida (score 0,56).

Integrity Metric

Descreve o tipo de alteração que pode ocorrer nas informações se a vulnerabilidade for explorada com sucesso. Classificada como:

• None (N): Sem impacto (score 0,0).
• Low (L): Modificação de algumas informações é possível, mas o atacante não tem controle sobre quais informações são modificadas (0,22).
• High (H): Atacante pode alterar qualquer informação no sistema (0,56)

Availability Metric
Descreve o nível de interrupção que pode ocorrer se um ataque for concluído com sucesso. Classificada da seguinte forma:

• None (N): Sem impacto na disponibilidade (score 0,0).
• Low (L): A performance do sistema é degradada (0,22).
• High (H): O sistema é completamente desligado (0,56)

Integrity Metric

Descreve o tipo de alteração que pode ocorrer nas informações se a vulnerabilidade for explorada com sucesso. Classificada:

• None (N): Sem impacto (score 0,0).
• Low (L): É possível a modificação de algumas informações, mas o atacante não tem controle sobre quais informações são modificadas (0,22).
• High (H): Atacante pode alterar qualquer informação no sistema (0,56)

Scope Metric

Descreve se o ataque pode afetar componentes além do item vulnerável, e é classificada de acordo com os critérios (sem score):

• Unchanged (U): A vulnerabilidade explorada afeta somente recursos sobre a mesma administração de segurança.
• Changed (C): A vulnerabilidade explorada pode afetar recursos além do sistema que contém a vulnerabilidade.

Interpreting the CVSS Vector

O CVSS Vector utiliza um formato em uma linha para informar a classificação de uma vulnerabilidade, e engloba as seis métricas descritas acima.
Exemplo: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

• CVSS versão 3
• Attack Vector: Network (score: 0.85)
• Attack Complexity: Low (score: 0.77)
• Privileges Required: None (score: 0.85)
• User Interaction: None (score: 0.85)
• Scope: Unchanged
• Confidentiality: High (score: 0.56)
• Integrity: None (score: 0.00)
• Availability: None (score: 0.00)

Calculating the Impact SubScore (ISS)

O ISS é calculado utilizando três métricas (Confidencialidade, Integridade e Disponibilidade), com a fórmula:

• ISS = 1 – [(1-Confidentiality)x(1-Integrity)x(1-Availability)]
• ISS = 1 – [(1-0,56)x(1-0)x(1-0)
• ISS = 0,56

Calculating the Impact Score

O Impact Score é calculado multiplicando o ISS pela Scope Metric. Se o Scope Metric for Unchanged, deve ser multiplicado por 6,42.

• Impact = 6,42 x ISS
• Impac = 6,42 x 0,56
• Impact = 3,60

Se o Scope Metric for Changed, a fórmula é:

• Impact = 7,52 x (ISS – 0,029) – 3,25 x(ISS – 0,02)^15

Calculating the Exploitability Score

Analistas podem calcular o Exploitability Score usando a seguinte fórmula:

• Exploitability = 8,22 x Attack Vector x Attack Complexity x Privileges Required x User Interaction
• Exemplo:
  Exploitability = 9,22 x 0,85 x 0,77 x 0,85 x 0,85
  Exploitability = 3,89

Calculating the Base Score

Com essas informações podemos calcular o CVSS Base Score, seguindo as regras:

• Se impacto =0, CVSS = 0
• Se o scope metric é Unchanged, calcular o base score somando o Impact e Exploitability Score.
• Se o scope metric é Changed, Base Score = (Impact + Exploitability) x 1,08.
• O maior base score possível é 10.

Considerando o exemplo inicial (Impact = 3,60, Exploitability 0,39), o Base Score é 7,5.

O CVSS Base Score pode ser classificado também por um rating, ao invés de numericamente.

CVSS Score    Rating:

• 0.0             None
• 0,1 – 3,9    Low
• 4,0 – 6,9    Medium
• 7,0 – 8,9    High
• 9,0 10,0    Critical

Validating Scan Results

Analistas normalmente validam o resultado de um scan fazendo uma investigação para confirmar a presença e a severidade das vulnerabilidades apontadas.

False Positives

Eventualmente o scan pode errar, devido a falta de privilégio ou algum erro no plugin utilizado. Quando um scanner aponta uma vulnerabilidade que não existe, é conhecido como falso positivo.

Por isso é importante um analista confirmar as vulnerabilidades apontadas.

Verificação de logs dos servidores, aplicações e dispositivos de rede, podem ter informações sobre tentativas de exploração da vulnerabilidade, bem como o uso do SIEM (Security Information and Event Management) para correlacionar múltiplas origens de logs.

Outra ferramenta utilizada pode ser software de “Configuration Management”, que vão listar informações do sistema operacional em uso.

Patch Management

Aplicar patches de segurança deve ser um dos principais itens de um programa de segurança da informação, mas muitas vezes é um item negligenciado.

Legacy Platforms

Eventualmente fabricantes descontinuam o suporte para os produtos, e continuar com esses sistemas/aplicações colocam a organização em risco.

Se não for possível atualizar, uma melhor prática é isolar o sistema o máximo possível, e aplicar medidas de segurança compensatórias, como aumentar o monitoramento e implementar regras de firewall.

Weak Configuration

Scans de vulnerabilidade também podem apontar configurações “fracas”, que podem incluir:

• Uso de configurações padrão
• Presença de contas inseguras (com senha padrão ou senha fraca, por exemplo)
• Portas desnecessárias abertas
• Permissões desnecessárias (diferente do “menor privilégio necessário”)

Error Messages

Mensagens de erro que contém mais informação do que deveriam também são um problema de segurança (ex. um sistema que foi para produção com logs “debug” ativo).

Insecure Protocols

Atualmente os protocolos são desenvolvidos e implementados pensando em segurança, mas protocolos mais velhos não tinham essa preocupação (ex. Telnet e FTP).
A opção é substituí-los por outros protocolos, como SSH e SFTP.

Weak Encryption

Criptografia é crucial para os controles de segurança, mas é necessário configurar adequadamente, sendo necessário escolher um bom algoritmo de criptografia/descriptografia, e a chave de criptografia utilizada no algoritmo.
Caso contrário será possível um atacante ter acesso aos dados.

Penetration Testing

Busca utilizar ferramentas para testar a segurança da organização, sendo realizado com autorização.

Necessário ferramentas e profissionais qualificados e tão determinados quanto atacantes reais.

Forma mais efetiva da organização ter visão completa das vulnerabilidades de segurança.

As organizações investem em diversos sistemas de segurança, como firewalls, IPS, scan de vulnerabilidades, equipe, SOC, e etc, e o teste de penetração não é para substituir nada disso, e sim para dar visibilidade que de outra forma não seria possível.

Mesmo que o teste de penetração tenha sucesso, ele mostrará fragilidades do ambiente, permitindo a remediação.

Threat Hunting and Bug Bounty Programs

Está intimamente relacionado ao teste de penetração, mas tem um propósito diferente.

Também visa emular um atacante, tentando imaginar como um atacante poderia atacar a organização, mas neste caso, ao invés de testar acessos e medidas de segurança, busca evidências de ataques já realizados com sucesso contra a organização. Segue a filosofia “Presumption of Compromise”.

Já os bug bounty programs permitem que analistas externos conduzam testes contra serviços publicados e incentivam fornecendo recompensas financeiras para quem conseguir explorar uma vulnerabilidade com êxito.

Penetration Test Types

Temos 3 classificações comuns para os testes de penetração:

• White-box: Também conhecido como Known environment test, porque é realizado sabendo as informações do ambiente e até credenciais. Mais efetivo, e completo, não precisa gastar tempo identificando alvos.
• Black-box: Também conhecido como Unknown environment test, emula o cenário real que um atacante encontraria, já que não é dada informações do ambiente. Necessário mais tempo para executar, mas mostra um cenário mais real com relação a ataques externos. Neste tipo a qualidade do penetration tester é fundamental. Um atacante mais qualificado do que o pen tester poderá encontrar brechas que o tester não encontrou.
• Gray-box: Conhecido como partially known environment test, é uma mistura dos dois anteriores, onde parte das informações podem ser fornecidas ao pentester. Podem ser fornecidos diagramas, mas não credenciais, por exemplo.

Rules of Engagement

Após escolher o time de assessment, é necessário definir as regras de engajamento (RoE), onde podemos destacar:

• Linha do tempo do engajamento e quando os testes serão feitos (podem ser feitos em horário não crítico, para evitar impacto no ambiente em produção).
• Locais, sistemas e aplicações incluídas e excluídas
• Manuseio dos dados, durante, e após a realização dos testes
• Comportamento esperado do alvo (shunning, blacklisting, etc)
• Quais recursos estarão disponíveis durante os testes (administradores, desenvolvedores e outros profissionais relacionados aos alvos)
• Questões legais devem ser tratadas
• Quando e como a comunicação vai ocorrer

Reconnaissance

O teste de penetração começa com a fase de reconhecimento, onde o analista busca o máximo de informações possíveis sobre a organização alvo. Mesmo em um white-box, informações adicionais (além das fornecidas pela organização) são necessárias.
É comum o analista tentar identificar redes wireless que possam dar acesso a rede interna (wardriving), sem precisar de acesso físico.

Running the Test

Durante o teste, o analista segue o mesmo processo usado por atacantes, e também as mesmas ferramentas (possivelmente) com as seguintes fases:

• Initial Access: Quando o atacante explora uma vulnerabilidade e ganha acesso a rede da organização.
• Privilege Escalation: Mudar o nível de acesso “inicial” para mais privilegiado/root.
• Pivoting/Lateral Movement: Ocorre quando o atacante usa o sistema comprometido para acessar outro destino/alvo na rede.
• Persistence: Atacante estabelece persistência, instalado backdoors e outros mecanismos que irão permitir o acesso remoto, mesmo que a falha inicial seja corrigida.

Cleaning Up

Ao término do penetration test, o analista apresenta os resultados, apontando possíveis falhas, e limpa os rastros de seu trabalho (remoção de software que tenham sido instalados e todo mecanismo de persistência).

Training and Exercises

As organizações podem fornecer treinamentos para seus funcionários, para ajudá-los a entender as funções de segurança.

Exercícios também são comuns, onde normalmente tem formato de competição, com atacantes e defensores.

• Red Team: Os membros do red team são os atacantes, e visam conseguir acesso aos sistemas/redes.
• Blue Team: São os defensores, que devem garantir a segurança e evitar que o red team tenha acesso indevido. Também monitoram o ambiente.
• White Team: Observadores/Juízes, que servem como árbitros quando ocorrem disputas entre os times. Também responsáveis por garantir que as atividades não gerarão impacto no ambiente.
• Purple Team: Ao término do exercício os times trocam informações para entender as táticas usadas. Esta combinação de conhecimento é referenciada como Purple Team.

Exercícios do tipo Capture the flag (CTF) também são uma forma de treinamento.

Até a próxima.