What are the best practices for tuning and updating your incident identification tools?

1 Assess your current tools

Before you start tuning and updating your incident identification tools, you need to assess their current performance and effectiveness. You can do this by reviewing the logs, alerts, reports, and metrics generated by your tools, and comparing them with your incident response goals and policies. You should look for any gaps, errors, false positives, false negatives, or inefficiencies in your tools, and identify the root causes and potential solutions.

2 Adjust the settings and parameters

One of the most common ways to tune and update your incident identification tools is to adjust their settings and parameters, such as thresholds, filters, rules, signatures, and profiles. These settings and parameters determine how your tools collect, analyze, and prioritize data, and how they alert you of potential incidents. You should adjust them according to your risk appetite, business context, and operational requirements. For example, you may want to lower the threshold for alerting on suspicious network activity, or add a new filter to exclude irrelevant data sources.

3 Update the data sources and feeds

Another way to tune and update your incident identification tools is to update the data sources and feeds that they use to gather and enrich information. Data sources and feeds can include internal and external sources, such as logs, network traffic, endpoints, databases, applications, threat intelligence, and vulnerability scanners. You should update them regularly to ensure that your tools have the most accurate and comprehensive data available. For example, you may want to add a new data source to cover a new asset or service, or update a threat intelligence feed to reflect the latest indicators of compromise.

4 Test and validate the changes

After you make any changes to your incident identification tools, you need to test and validate them to ensure that they work as intended and do not cause any adverse effects. You can do this by running simulations, scenarios, or exercises that mimic real or hypothetical incidents, and observing how your tools react and perform. You should also monitor the feedback, results, and outcomes of your changes, and measure their impact on your incident response capabilities. For example, you may want to test how your tools detect and alert on a ransomware attack, or measure how your changes affect the false positive rate or the response time.

5 Document and communicate the changes

Finally, you need to document and communicate the changes that you make to your incident identification tools, both internally and externally. You should document the reasons, objectives, procedures, and results of your changes, and store them in a central repository that is accessible and auditable. You should also communicate the changes to your stakeholders, such as your incident response team, management, auditors, regulators, or customers. You should explain the benefits, risks, and implications of your changes, and solicit their feedback and input. For example, you may want to document how you updated a rule to detect a new malware variant, or communicate how you adjusted a parameter to comply with a new regulation.