[Security Solution] Trusted field is displaying empty in add endpoint exception modal for unsigned alerts

[ghost]

Describe the bug
Trusted field is displaying empty in add endpoint exception modal for unsigned alerts

Build Details:

VERSION: 7.14.0 BC4
BUILD: 42656
COMMIT: 82a4f6a7fa23946667599787cdb1b2d82c1d0dfb
ARTIFACT: https://staging.elastic.co/7.14.0-b3779639/summary-7.14.0.html

Browser Details:
N/A

Preconditions

1. Kibana users should be logged in.
2. endpoint should be installed.
3. unsigned alerts should be generated.

Steps to Reproduce

1. Navigate to Alerts tab of security.
2. Click on add endpoint exception.
3. Observe that Trusted field is displaying empty in add endpoint exception modal for unsigned alerts

Actual Result
Trusted field is displaying empty in add endpoint exception modal for unsigned alerts

Expected Result
Trusted field should displaying empty in add endpoint exception modal for unsigned alerts.

What's Working

• This issue is not occurring on 7.13.4
  

What's Not Working

• N/A

Screen-Shot

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[ghost]

@manishgupta-qasource Please review!!

[manishgupta-qasource]

Reviewed & assigned to @MadameSheema

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[MadameSheema]

@peluja1012 @spong can you please take a look at this? thanks :)

[peluja1012]

Hi @deepikakeshav-qasource, could you please check what the value of file.Ext.code_signature looks like for the alert in question?

[ghost]

Hi @peluja1012,

Please find the below details of file.Ext.code_signature.

Malware Detection
Screenshot:

JSON:
Malware_detection.txt

Malware Prevention
Screenshot:

JSON:
malware_prevention.txt

Please let us know if anything else is required from our end.

Thanks!!

[peluja1012]

Thanks, Deepika. It looks like the Endpoint is not populating values for file.Ext.code_signature.trusted. @ferullo is this expected?

[ferullo]

@intxgo this looks like an Endpoint bug, right? "code_signature": {"exists": false} looks like nonsensical data. I'd expect Endpoint to just not include the code signature block when there is no signature. Or am I missing something?

@peluja1012 do you agree this is not a critical issue for 7.14.0? I want to make sure it is prioritized correctly.

cc @softengchick

[MadameSheema]

After a conversation with @peluja1012, we agree that this issue is not critical for 7.14 release.

[intxgo]

code_signature contains the primary signature, whilst Ext.code_signature contains an array with all code signatures (the primary and any secondary signatures). Obviously we should never see a case not to have a primary signature but have some secondary signatures (technically secondary signatures are attached as a metadata to the primary signature). Now the {"exists": false} was already there for the primary signature (I guess to simplify queries or it's a leftover from Endgame sensor, i.e. it was helpful in sensor and just was carried over to Elastic Endpoint). I found it logical to duplicate the data about primary signature in Ext.code_signature array even if it's {"exists": false}, but we may filter it out if needed.

[ferullo]

But even the code_signature value (not Ext.code_signature contains just {"exists": false} as seen in this screenshot.

#106663 (comment)

for this data I wonder why code_signature is there at all. Should it be? Is that how unsigned binaries are reported? Or is it an Endpoint bug?

{
  "file": {
    "code_signature": {
      "exists": false
     },
    "Ext": {
      "code_signature": {
        "exists": false
      }
    }
}

[intxgo]

I think I may have an idea what it was useful for, I guess this exists boolean was convenient or was needed for filterlib, this may be the case of suppressing alerts. But yes, that's how they are reported. Speaking about signatures, the exists is not a signature field, it's just our marker so it's a bit funny that it goes with other signature properties.

[ferullo]

👍 Thanks @intxgo . In that case it sounds like Endpoint is working as designed.

@peluja1012 is this something Kibana can work around?

[ghost]

Hi @MadameSheema ,

We have validated this ticket on 7.15.0-SNAPSHOT build and found that issue is Still Occurring.

Build Details:

Version:7.15.0 SNAPSHOT
Commit:aa12d107c38c5cda96fc32bcd1f8226df172826a
Build:43370

Screenshot:

Thanks.

[MadameSheema]

Closing since is working as expected.