Configuring remediation target rules
By configuring remediation target rules, you can set the expected time frame for addressing findings, similar to how service level agreements (SLAs) set deadlines for fixing vulnerabilities.
- Critical Risk Rating Rule: A remediation target with a 1-Critical risk rating, a remediation target of 15 days, and a reminder of 7 days before the target date.
- Less Critical Risk Rating Rule: A remediation target with either a 2-High or 3-Medium risk rating a remediation target of 30 days, and a reminder of 7 days before the target date.
- Medium-High RIsk Rating Rule: A remediation target with a 4-Low risk rating a remediation target of 45 days, and a reminder of 7 days before the target date.
Create or edit remediation target rules
Create remediation target rules to ensure the timely remediation of high-risk vulnerabilities by setting up a remediation target rule at the findings level.
Before you begin
Role required: See Access control lists (ACLs) for administration rules
Procedure
Recalculate a remediation target date
The remediation target (RT) date defines when a finding must be remediated. Recalculation verifies that RT dates stay accurate and reflect the latest risk rating updates. When a finding’s risk rating changes, the system can recalculate RT dates using the most recent update date, helping maintain accurate SLAs and avoid outdated or overdue target dates.
Before you begin
Role required: admin
About this task
Procedure
What to do next
Examples of recalculating a remediation target date
The following examples show how the system recalculates the remediation target date based on different rule selections and risk rating changes.
- Low risk: 30 days
- Medium risk: 15 days
- High risk: 10 days
| Target from (date) | Field change time | Initial risk (Target (days)) → New risk (Target (days)) | Existing RT date | Recalculated RT date | What happens |
|---|---|---|---|---|---|
| Default calculation | |||||
| Feb 1 | Feb 10 | Medium (15 days) → High (10 days) | Feb 16 (retained) | Feb 20 | The recalculated RT date isn’t applied. The system keeps the original RT date: Target from (date) + Target (days) → Feb 1 + 15 = Feb 16. |
| Recalculate from risk change date | |||||
| Feb 1 | Feb 10 | Medium (15 days) → High (10 days) | Feb 16 | Feb 20 (applied) | Uses the recalculation formula: Field change time + Target (days) → Feb 10 + 10 = Feb 20. |
| Recalculate from risk change date and always set to earliest target date | |||||
| Feb 1 | Feb 10 | Medium (15 days) → Low (30 days) | Feb 16 (applied) | Mar 12 | Compares the existing RT date (Feb 16) with the recalculated date (Feb 10 + 30 = Mar 12) and selects the earliest date → Feb 16. |
| Recalculate from risk change date and set to earliest target date only when risk rating increases | |||||
| Feb 1 | Feb 10 | Low (30 days) → High (10 days) | Mar 3 | Feb 20 (applied) | Because the risk increased, the system compares the existing RT date (Mar 3) with the recalculated date (Feb 20) and applies the earlier date → Feb 20. |
| Feb 1 | Feb 10 | High (10 days) → Low (30 days) | Feb 11 | Mar 12 (applied) | Because the risk decreased, no comparison is performed. The system sets RT date to: Field change time + Target (days) → Feb 10 + 30 = Mar 12. |
Re-evaluate the remediation properties of the records in the Security Exposure Management Workspace
Evaluate the assignments, remediation target date, remediation tasks, exceptions, and risk score for a set of records (VITs, AVITs, CVITs or TRs) in the Security Exposure Management Workspace.
Before you begin
- sn_vul.vulnerability_analyst, or sn_vul.vulnerability_admin for host vulnerable items (VITs)
- sn_vul.app_sec_manager for application vulnerable items (AVITs)
- sn_vul_container.vulnerability_analyst or sn_vul_container.vulnerability_admin for container vulnerable items (CVITs)
- sn_vulc.admin for configuration test results (CTRs)
About this task
Previously, applying rules to all records was necessary to obtain the latest assignments, remediation target dates, risk scores, and remediation tasks, which was time-consuming. Now, you can selectively evaluate and update these properties for specific records, reducing processing time. This update also allows for refining the remediation process based on the updated properties. Furthermore, evaluating exception rules for selected records is now possible, streamlining the process.
Procedure
Result
The properties are updated for the selected records. You can check the Work notes of the records for the previous and latest values of the updated remediation properties.