3e. Tune or deprecate

In this final step of the development lifecycle, observations on efficacy and performance are captured as feedback to determine if a rule is appropriately functioning, and if not, it is a candidate for tuning or deprecation. Other reasons to tune may be to account for new research or platform features. There may also just need to be economical decisions made, since maintaining a growing ruleset can get costly quickly.

As previously mentioned, product teams will need to balance the tuning as much as possible to keep it compatible with the collective environments using the platform. They will also need to balance from over tuning and making the logic either too atomic or too comprehensive. This is useful because then it allows users to put the final touches on the logic, as some tend to prefer more exhaustive alerting to allow the interpretation to be made by human triage efforts, whereas others tend to want to minimize noise at all costs.

Also, sometimes tuning the logic does make a lot of sense, however, it is specific to a certain environment. In those instances, it may be better to add exceptions within that environment only, as opposed to the global rule set.

Details of how to develop and maintain rules will be discussed in detail in chapter 9.

Fig. 40 Open tuning issues for Elastic SIEM rules