[SECURITY_SOLUTION][ENDPOINT] Add creation of Trusted Apps Agnostic List

[paul-tavares]

Summary

Adds a service to the Lists plugin to create the Global Trusted Apps agnostic list with a reserved name as well as a new list type named endpoint-trusted-apps.

These changes will be leveraged by the Trusted Apps API

[elasticmachine]

Pinging @elastic/endpoint-management (Team:Endpoint Management)

[elasticmachine]

Pinging @elastic/endpoint-app-team (Feature:Endpoint)

[paul-tavares]

jenkins test this

[paul-tavares]

@marshallmain @madirey In attempting to refactor this based on feedback, I'm trying to understand which of the methods in exceptions_list_client.ts need to ensure it has a call to createTrustedAppsList(). This class seems to have methods to create Endpoint List Items (*EndpointListItems) as well as methods to create Exceptions List Items (*ExceptionsListItems). The *EndpointListItems methods seem to just call the Exceptions one and set the Namespace to agnostic + use the endpoint_list value for list_id, while the *ExceptionsListItems methods seem to allow for both to be defined on input.

I assume that the call to createTrustedApps() method needs to happen in the *ExceptionListItem methods since that is the API we'll be using for Trusted app - do I have that right?

[paul-tavares]

I believe I had addressed all of the comments provided. If you get a chance, please give it another look

[marshallmain]

Since this list has different restrictions I would use a different list type such as endpointTrustedApps

[madirey]

Agreed, we should be thinking about this as a different type for at least 2 reasons that I can think of. 1) to ensure that it doesn't have any side effects on existing code / API consumers, 2) in case we want to switch on this for schema customizations later one (I realize we can switch on the id/name instead, but it might be a good idea to have both available since we know that future features will require multiple lists, e.g. per-policy trusted apps or per-policy exceptions).

[madirey]

I thiiiiink the convention for IDs/types like this is hyphen-delimited though, as opposed to camelcase. So maybe something like trusted-apps. Could be wrong, and super nitpicky anyway, but maybe look for some examples before changing.

[paul-tavares]

Sounds good. I will create a new type (was trying to minimize the impact to manifest_manager, but its a minor refactoring there).

[paul-tavares]

All, I have refactored this PR to include only the service that will allow for the Trusted Apps list to be created. Please take a look when you have a chance 😃

[paul-tavares]

@madirey , @marshallmain ,
There are some check/test failures due to this change. Before I go down the path of adjusting those to account for this new value, I just want to confirm that this is the correct change to do here.

[madirey]

The reason I thought you might want a different list type if because of things like this:

kibana/x-pack/plugins/lists/server/routes/create_exception_list_item_route.ts

Lines 75 to 90 in 88c0631

	if (exceptionList.type === 'endpoint') {
	for (const entry of entries) {
	if (entry.type === 'list') {
	return siemResponse.error({
	body: `cannot add exception item with entry of type "list" to endpoint exception list`,
	statusCode: 400,
	});
	}
	if (endpointDisallowedFields.includes(entry.field)) {
	return siemResponse.error({
	body: `cannot add endpoint exception item on field ${entry.field}`,
	statusCode: 400,
	});
	}
	}
	}

... if that check is valid, and you don't need any additional checks, you might get away with using type endpoint. But it seems like you might want your own type. If you add a different type, and your own route, I think you should add validation to that route so that requests to create your list type are rejected.

@yctercero do you have any input on this?

[madirey]

This is one of the reasons why I think this gets weird if we use a different route to manage the list, rather than having it managed by the lists plugin, btw... if you add your own route, you still will need validation to ensure that lists can't work with your list type.

[paul-tavares]

I'm going revert this type back and only introduce the method to create the trusted apps list. We'll revisit later when we have more clarity. Perhaps we just add the new type to the exceptions service methods in support of Trusted Apps? Maybe? 😄

[paul-tavares]

Question: since this validation you referenced is in the exceptions list route, I don't think it matters to trusted apps - right?

(Still agree that we should introduce code to prevent attempts to update a Trusted Apps list item in these APIs)

[marshallmain]

The problem is here we shouldn't use endpoint as the type - the trusted apps list is not the same as the endpoint exceptions lists. When we create the trusted apps list it needs to have its own type so I think the type has to be added with the method to create the list. The type needs to be included in exceptionListSoSchema for the saved object creation type check to pass, so I think it's logical to include the additional type here. We do need additional validation to prevent adding trusted apps through the generic create_exception_list_item route - for now the simplest approach would be to just add another check like if(exceptionList.type == TRUSTED_APPS_LIST_TYPE) return 400.

We may want to consider again making each type of list use their own route so that the route handler knows what type of list to expect and can immediately return 400 if a request attempts to add to a different type of list. This makes the handlers more independent of each other - create_exception_list_item_route would only be responsible for checking that you're adding the item to a detection exception list and doesn't care what other types of lists may exist. This would not be done in this PR, but supports the idea of keeping the trusted apps route separate from the existing routes.

Separating the lists into different handlers by list type also allows us to do all the schema validation up front in the route validation function - it's somewhat confusing to have validateEndpointExceptionItemEntries called in the middle of the route handler to do more schema validation in the endpoint case.

[paul-tavares]

I'll create a separate issue to introduce a new type for use by Trusted apps. I attempted on this one, but looks like it had impacts not only to the schemas, but also types used on the Detections Engine (exceptions?) UI. We'll come back around to it.

[paul-tavares]

jenkins test this

[paul-tavares]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 996ac21

Build metrics

page load bundle size

id	value	diff	baseline
lists	164.2KB	+229.0B	164.0KB

History

• 💔 Build #68779 failed 76846b8
• 💚 Build #67998 succeeded 2235d07
• 💚 Build #67772 succeeded 53285e9

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