Vulnerability Response regras de destino de correção

  • Versão de lançamento: Washingtondc
  • Atualizado 1 de fev. de 2024
  • 4 min. de leitura

    • As regras de destino de correção definem o intervalo de tempo esperado para corrigir itens vulneráveis (IV), assim como os SLAs fornecem um intervalo de tempo para corrigir a própria vulnerabilidade. Por exemplo, se um ativo contiver dados de PCI (dados de cartão de crédito), a vulnerabilidade nesse item precisará ser corrigida em 30 dias de acordo com o PCI DSS.

    Os gerentes de vulnerabilidade podem criar regras de destino de correção definindo:
    • A meta de correção
    • O destino do lembrete
    • Os destinatários do lembrete e da notificação - que devem ser notificados quando os itens vulneráveis (IVs) passarem da data de destino do lembrete ou da correção e não forem corrigidos.

    Os analistas e gerentes de vulnerabilidade podem ver a data de destino da correção no formulário do item de vulnerabilidade e nas exibições de lista, desde que os itens vulneráveis não estejam no estado Adiado, Resolvidoou Encerrado. As regras de destino de correção serão executadas na importação e serão executadas novamente se um IV for reaberto.

    A data de destino da correção é codificada por cores na exibição da lista de IVs como pontos, da seguinte forma:
    • Itens vulneráveis que não atingiram a data de notificação são mostrados em verde.
    • Itens vulneráveis que se aproximam da data de meta de correção são mostrados em laranja.
    • Itens vulneráveis após a data de meta de correção são mostrados em vermelho.

    Um e-mail de resumo, por regra de destino de correção, é enviado quando um ou mais IVs estão se aproximando da data de destino de correção ou a data de destino de correção passou.

    As regras de destino de correção podem ser desativadas ou excluídas

    Quando uma regra é desativada, as datas de destino de correção atuais dos IVs aos quais ela foi aplicada são apagadas. Se um IV atender a qualquer regra ativa, essa regra será aplicada, caso contrário, o IV não terá regra ou data de destino e seu status será Sem meta.

    Quando as regras são excluídas, a data de destino da correção e os campos relacionados em IVs encerrados, adiados ou resolvidos são preservados. A data de destino da correção e os campos relacionados em IVs não encerrados são limpos e todas as regras dependentes são reaplicadas.

    Cenário de regra de destino de correção

    Quando várias regras de destino de correção são aplicadas ao mesmo item vulnerável, a regra mais restritiva é aplicada.
    Nota:
    As metas de correção são calculadas a partir da data da última abertura mais o número de dias (medidos como incrementos de 24 horas).

    A partir da V17.1, as metas de correção são calculadas a partir da meta de (data). O valor padrão permanece Data da última abertura.

    Por exemplo, se um item vulnerável atender à condição para duas regras de destino de correção:

    Cenário: item vulnerável aberto pela última vez em 01/03/2018 às 10:00:00.
    • Regra de destino de correção 1: aberta pela última vez em 03/07/2018; a meta de correção é de 15 dias desde que foi aberta pela última vez; A data de destino da correção calculada é 16/03/2018 10:00:00.
    • Regra de destino de correção 2: aberta pela última vez em 10/03/2018; a meta de correção é de 10 dias desde que foi aberta pela última vez; A data de destino da correção calculada é 11/03/2018 10:00:00.
    Neste cenário, a Regra de destino de correção 2 se aplica ao item vulnerável, já que ele tem a data mais restritiva. 10 dias desde que o item vulnerável foi identificado pela primeira vez, versus 15 dias.
    Nota:
    Depois que a Regra de destino de correção for definida, as datas de destino de correção serão calculadas pelo trabalho programado Evaluate remediation targets .

    Sobre o trabalho programado Avaliar destinos de correção

    Evaluate remediation targets é executado uma vez às 4:00:00 diariamente.

    Ele itera por meio de todas as regras de vulnerabilidade ativas, começando pelas regras com a data de meta de correção mais antiga. Ele analisa todos os itens vulneráveis que:
    • Não estejam em um estado Encerrado, Adiadoou Resolvido.
    • Não tem data de meta de correção.
    • Tenha uma data de destino de correção posterior à data na regra de destino de correção.

    Evaluate remediation targets adiciona uma data de destino de correção, se não houver uma, ou se uma regra resultar em uma data anterior à do registro, ele atualizará a data de destino existente. Por fim, ele atualiza os campos Destino de correção e Status da correção no formulário de item vulnerável.

    Depois que o Evaluate remediation targets for executado, as notificações disponíveis serão enviadas.

    Evaluate remediation targets limpa os campos de correção no IV e para de enviar notificações.

    Começando com Vulnerability Response v19.0, a propriedade sn_sec_cmn.evaluate_targetmissed_records, quando habilitada, impede que o trabalho programado Remediation Target Rules ] avalie IVs ausentes. Esta propriedade está habilitada por padrão.

    Reaplicar regras de destino de correção

    Ao alterar uma regra de destino de correção, use o botão Aplicar mudanças na página da lista Regras de destino de correção para executar novamente todas as regras alteradas em todos os IVs abertos ativos, exceto aqueles no estado Encerrado, Adiado ou Resolvido. Dependendo de quantos IVs você tem, isso pode levar algum tempo.
    Nota:

    Se o trabalho programado, Evaluate remediation targets estiver em execução, você não poderá iniciar um processo de reaplicação. No entanto, se um processo de reaplicação já estiver em execução e o trabalho programado que ele acionou, eles serão executados em paralelo.

    Os processos de reaplicação em Vulnerability Response e Application Vulnerability Response são independentes e podem ser executados em paralelo.