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 vulnerabilidade em si. 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.
- O destino de correção
- O destino do lembrete
- O lembrete e os destinatários da notificação: Quem devem ser notificados quando os itens vulneráveis (VIS) ultrapassarem a data de destino de lembrete ou correção e não tiverem sido corrigidos.
Os analistas e gerentes de vulnerabilidades podem ver a data de destino de correção no formulário de item de vulnerabilidade e nas exibições de lista, desde que os itens vulneráveis não estejam em Adiado , Resolvido ou Encerrado estado. As regras de destino de correção são executadas na importação e executadas novamente se uma VI for reaberta.
- Os 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 destino de correção são mostrados em laranja.
- Itens vulneráveis após a data de destino 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 VIS estão se aproximando da data de destino de correção ou a data de destino 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 destino de correção atuais para o VIS ao qual ela foi aplicada são apagadas. Se uma VI atender a qualquer regra ativa, essa regra será aplicada, caso contrário, a VI não terá regra ou data de destino e seu status será Nenhum destino .
Quando as regras são excluídas, o Destino de correção Os campos de data e relacionados em VIS Encerrado, Adiado ou Resolvido são preservados. . Destino de correção Os campos de data e relacionados em VIS não encerrados são limpos e todas as regras dependentes são reaplicadas.
Cenário de regra de destino de correção
A partir da V17.1, os destinos de correção são calculados a partir do Destino 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 destino de correção:
- Regra de destino de correção 1: Aberto pela última vez em 07/03/2018; o destino de correção é de 15 dias desde que foi aberto pela última vez; a data de destino de correção calculada é 03/16/2018 10:00:00.
- Regra de destino de correção 2: Aberto pela última vez em 10/03/2018; o destino de correção é de 10 dias desde que foi aberto pela última vez; a data de destino de correção calculada é 03/11/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 Encerrado , Adiado ou Resolvido estado.
- Não tem data de destino de correção.
- Ter 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 à data no registro, ela atualiza a data de destino existente. Por fim, ele atualiza o. Destino de correção e. Status de correção campos no formulário de item vulnerável.
Uma vez que Evaluate remediation targetsas notificações disponíveis são enviadas.
Evaluate remediation targets Limpa os campos de correção no VI e interrompe o envio de notificações.
. sn_sec_cmn.evaluate_targetmissed_recordsa propriedade, quando habilitada, impede Remediation Target RulesTrabalho agendado da avaliação de Vs perdidos. Esta propriedade está habilitada por padrão.
Reaplicando regras de destino de correção
Se o trabalho agendado, Evaluate remediation targetsnão é possível iniciar um processo de reaplicação. No entanto, se um processo de reaplicação já estiver em execução e o trabalho agendado acionado por ele, eles serão executados em paralelo.
Reaplicar processos em Resposta a vulnerabilidades e. Resposta a vulnerabilidades de aplicações são independentes e podem ser executados em paralelo.