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

fix evidence not counting for the correct profile #1044

Merged

Conversation

AlyaGomaa
Copy link
Collaborator

@AlyaGomaa AlyaGomaa commented Oct 23, 2024

  • some evidence had attacker ip X but profile IP Y. this is fixed in this PR.

@AlyaGomaa AlyaGomaa merged commit e5a7016 into develop Oct 23, 2024
48 checks passed
@AlyaGomaa AlyaGomaa deleted the alya/fix-evidence-not-counting-for-the-correct-profile branch October 23, 2024 18:56
@eldraco
Copy link
Collaborator

eldraco commented Oct 24, 2024

But what was the problem? why it went down?

@AlyaGomaa
Copy link
Collaborator Author

AlyaGomaa commented Oct 24, 2024

here's what was happening

some detections like "malicious downloaded file" have 2 evidence, one for the src and one for the dst IP. the ProfileID of each evidence should be the profile of the attacker
so, what should be happening is:
1st evidence:

  • src: srcip 192.168.1.113
  • target: dst IP 8.8.8.8
  • profile: srcip192.168.1.113

2nd evidence

  • src: 8.8.8.8
  • target: 192.168.1.113
  • profile: 8.8.8.8

in all evidence the profile should be the profile of the srcip.


The issue was in some detections, I was doing

  • src: srcip 192.168.1.113
  • target: dst IP 8.8.8.8
  • profile: 8.8.8.8 (this is the wrong profile)

so the evidence was reported correctly in the alerts.json (with the correct src and target), but the profile is wrong (not reported to alerts.json)

so the threat level of that evidence was added to the accumulated threat level of profile 8.8.8.8 instead of profile 192.168.1.113 right?
so for example if the acc threat level of the profile_192.168.1.113 is 49.9
and the accumulated threatl level of profile_8.8.8.8 is 0.1

that wrong evidence added to the accumulated threat level of profile_8.8.8.8 which was 0.1 .so it became 0.4 for example, and was reported in alerts.json as 0.4.

so in alerts.json we have some correct evidence, accumulating the threat levels normally, (e.g 5,10,20,50) and wrong evidence, accumulating the threat level of another profile (e.g 5,10,20,50, 0.4, ..), and reporting it with the correct src and target IPs.

that was the drop in the acc threat levels in the issue #1043

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

Successfully merging this pull request may close these issues.

2 participants