[Security Solution][Event Filters] Warning callout for incomplete code signature entries

[parkiino]

Summary

Navigate to Security Solution > Manage > Event Filters > Add Event Filter

• Warning callout shown when code signature field is incomplete (i.e. process.code_signature.subject_name w/o process.code_signature.trusted or vice versa)
• For mac operating systems, process.code_signature.team_id is also accepted as an equivalent to subject_name
• Warning callout is also shown for nested entries for this code signature field: process.Ext.code_signature
• Unit Tests

Paired PR for endpoint exceptions: #198245

Screenshots

MAC

NESTED

Followup prs: need to address user being allowed to choose the nested field: process.Ext.code_signature for a non-nested entry, need to address what happens when a user chooses false instead of true for the trusted field option

[elasticmachine]

Pinging @elastic/security-defend-workflows (Team:Defend Workflows)

[szwarckonrad]

I’d recommend simplifying the code to avoid nested iterations. Consider using a single for loop with early returns. Here’s a rough pseudocode example

for (e of entries) {
    if (e.type === 'nested' && e.field === 'process.Ext.code_signature) {
        const includesNestedName = e.entries.some(entry => entry.field === 'subject_name')
        const includesNestedTrusted = e.entries.some(entry => entry.field === 'trusted')
        if (includesNestedName !== includesNestedTrusted) {
             return true // Mismatch found, no need to continue
     } else {
           if (e.field === 'process.code_signature.subject_name' ||
           (os.includes('macos') && e.field === 'process.code_signature.team_id')
    ) {
      name = true;
    } if (e.field === 'process.code_signature.trusted') {
      trusted = true;
    }
   if (name !== trusted) {
       return true; // Mismatch found in outer entries
   }
return false; // No mismatch
}

[szwarckonrad]

To avoid ? and checks for os you can go with
const { os_types = ['windows'], entries = [] } = items[0] || {};
if items[0] is undefined then it will default to os_types = ['windows'] and empty entries, otherwise it will be overwritten with what items[0].os_types and .entries carries.

[ashokaditya]

I'm wondering if either code block (including the suggestion) here is going to make sense in 3 months? Can we break it down into smaller chunks of contextual logic? Something like

isNestedTrustedEntry();
isNestedNameEntry();
isNameEntry();
isTrustedEntry();

and use that to compose a boolean statement?

If you do decide to break them into chunks, perhaps it would be a good idea to write unit tests for those so that we understand what that logic does.

[szwarckonrad]

Good idea @ashokaditya!

[parkiino]

Hi, I tried to incorporate some of your logic for the single for loop with early returns. I could only do it for the nested condition however because the name and trusted fields need to be checked in all the entries.

[szwarckonrad]

Nit: I believe you can pass the tagName="p" prop to <FormattedMessage />, and it will render the message inside a

tag.

[vitaliidm]

should this logic apply to other code_signature fields like:

[vitaliidm]

I think it would be better to split into 2 tests

[vitaliidm]

let's split it into 2 cases for better maintainability and readability

[ashokaditya]

I'm wondering if either code block (including the suggestion) here is going to make sense in 3 months? Can we break it down into smaller chunks of contextual logic? Something like

isNestedTrustedEntry();
isNestedNameEntry();
isNameEntry();
isTrustedEntry();

and use that to compose a boolean statement?

If you do decide to break them into chunks, perhaps it would be a good idea to write unit tests for those so that we understand what that logic does.

[szwarckonrad]

Looks great, thanks for incorporating my suggestions!

[vitaliidm]

Thank you for addressing comments on tests.

One question, I still have is regarding other signature fields - #193749 (review)

[parkiino]

should this logic apply to other code_signature fields like:

Hi @vitaliidm so technically that field is a nested only field, which we do check for incomplete code signatures if it's in a nested condition entry. I guess it's a bug that it is shown as an option for non-nested condition entries, but fixing that would be for a different ticket.

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: c73d88f

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	5920	5921	+1

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/securitysolution-exception-list-components	95	96	+1
@kbn/securitysolution-list-utils	161	162	+1
total			+2

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	20.5MB	20.6MB	+5.7KB

Unknown metric groups

API count

id	before	after	diff
@kbn/securitysolution-exception-list-components	106	107	+1
@kbn/securitysolution-list-utils	209	211	+2
total			+3

History

• 💚 Build #238855 succeeded 2398409
• 💛 Build #236553 was flaky 3580038
• 💔 Build #236472 failed fc76619

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[kibanamachine]

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/11211353751

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation