Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SC_Email_Body_with_Known_Phishing_URL takes a long time to populate. #445

Open
PhilOrdo opened this issue Nov 28, 2022 · 4 comments
Open

Comments

@PhilOrdo
Copy link
Contributor

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 added a commit that referenced this issue Feb 20, 2023
…own_Phishing_URL taking a long time to load.
dcuellar322 added a commit that referenced this issue Feb 20, 2023
PhilOrdo added a commit that referenced this issue Feb 28, 2023
…hanges

Issue #445 & #434 : Attemping to fix issue with SC_Email_Body_with_Kn…
@dcuellar322
Copy link
Collaborator

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
Copy link

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
Copy link

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Working
Development

No branches or pull requests

3 participants