Resposta a vulnerabilidades regras de destino de correção
As regras de destino de correção definem o intervalo de tempo esperado para corrigir itens vulneráveis (VI), assim como os SLAs fornecem um intervalo de tempo para corrigir a própria vulnerabilidade. Por exemplo, se um ativo contiver dados PCI (dados de cartão de crédito), a vulnerabilidade nesse item precisará ser corrigida em 30 dias de acordo com o PCI DSS.
- 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 meta de lembrete ou correção e não tiverem sido corrigidos.
Os analistas e gerentes de vulnerabilidade podem ver a data da meta de 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 são executadas na importação e executadas novamente se um IV for reaberto.
- 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 meta de correção, é enviado quando um ou mais IVs estão se aproximando da data de meta de correção ou quando a data de meta de correção já passou.
As regras de destino de correção podem ser desativadas ou excluídas
Quando uma regra é desativada, as datas de meta de correção atuais dos IVs aos quais ela foi aplicada são apagadas. Se um VI atender a qualquer regra ativa, essa regra será aplicada, caso contrário, o VI não terá uma regra ou data de destino e seu status será No Target.
Quando as regras são excluídas, a data de meta de correção e os campos relacionados em IVs encerrados, adiados ou resolvidos são preservados. A data de meta de correção e os campos relacionados em IVs não encerrados são limpos e todas as regras dependentes são reaplicadas.
Cenário da regra de meta de correção
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 de duas regras de meta de correção:
- Regra de meta de correção 1: Aberto pela última vez em 03/07/2018; a meta de correção é de 15 dias desde que foi aberta pela última vez; A data da meta de correção calculada é 16/03/2018 10:00:00.
- Regra de meta de correção 2: Aberto pela última vez em 10/03/2018; a meta de correção é de 10 dias desde que foi aberta pela última vez; A data da meta de correção calculada é 11/03/2018 10:00:00.
Sobre o trabalho agendado Avaliar metas de correção
Evaluate remediation targets é executado uma vez às 4:00:00 diariamente.
- Não estão em um estado Encerrado, Adiadoou Resolvido.
- Não têm data de meta de correção.
- Ter uma data de meta de correção posterior à data na regra de meta de correção.
Evaluate remediation targets adiciona uma data de meta de correção, se não existir uma, ou se uma regra resultar em uma data anterior à do registro, ele atualizará a data de meta existente. Por fim, ele atualiza os campos Meta de correção e Status da correção no formulário de item vulnerável.
Depois que o Evaluate remediation targets é executado, as notificações disponíveis são enviadas.
Evaluate remediation targets limpa os campos de correção no IV e interrompe o envio de notificações.
A partir da versão Resposta a vulnerabilidades v19.0, a propriedade sn_sec_cmn.evaluate_targetmissed_records, quando habilitada, evita que o trabalho agendado Remediation Target Rules ] avalie IVs ausentes. Esta propriedade está habilitada por padrão.
Reaplicar regras de destino de correção
Se o trabalho agendado, 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 agendado que ele acionou, eles serão executados em paralelo.
Os processos de reaplicação em Resposta a vulnerabilidades e Resposta a vulnerabilidades de aplicações são independentes e podem ser executados em paralelo.