SC_Email_Body_with_Known_Phishing_URL takes a long time to populate.

[PhilOrdo]

This signature runs on an automation that adds phishing URLs and keeps the rule in Vetting status. We took a look at this before with Danny and found that the revision history had become bloated from the automated changes and imposed a limit to the number of visible revisions. This rule continues to sit at "Loading ..." until eventually producing an nginx error and appearing in released status after a while.

[dcuellar322]

This issue is a duplicate of #434, suggest we close one.

Could I get some clarity on if this is still an issue? After I moved the revisions to a separate modal?

[dspruell-i01]

This issue is a duplicate of #434, suggest we close one.

Could I get some clarity on if this is still an issue? After I moved the revisions to a separate modal?

Flagging question for @PhilOrdo, and also wanted to get input for @dcuellar322 on which of #434 or #452 we want to close out to de-dupe.

[dspruell-i01]

Reflecting on open questions:

Q: Is this still an issue, or did the change that moves revisions into a separate modal have a positive effect? A: The reported issue seems to be resolved - loading the edit modal takes a reasonable amount of time to load the signature.

Q: How to handle revision history limits? A: For automated signature modifications, we should not track revision history from automated updates.

Q: How to handle revision tracking limits? A: We should maintain a hard limit by revision count. A limit of 25 is probably fine. On update, we should remove the oldest revision.

@dcuellar322 and @azazelm3dj3d let us know if the above helps scope this out more clearly, and whether this works to keep in the same issue or whether this justifies splitting the revision limit topics out into their own distinct issues.

[dspruell-i01]

From 7/10 call:

• We will break out additional issues as necessary from the above
  • New change issue to update any scripts on the kb server that call into ThreatKB should be updated to specify the parameter to not bump revision (on rule update, etc.)
  • First, a new change issue to implement a limit revision count
  • Second, a new change to implement a delete operation to remove the oldest object over the revision limit

Third, preferred approach to deletion of old revisions: for the automation rules, create new copy of each rule to move forward with no rule revision history. Will depend on the rule update being done by rule ID (event ID) or rule name, to get the update done correctly.

@dspruell-i01 to run the issue updates and coordination for the above.