[Cloud Security][CDR] Update Wiz vuln privileges

[CohenIdo]

Solves:

• https://github.com/elastic/security-team/issues/9829

Summary

Update kibana_system privileges:

• Include the privilege to create the latest Transform index.
• Include the privilege to read from the Transform's source index.

Integration PR:

• Add Latest Transform - Wiz Vulnerabilities integrations#10895

Please note: We considered using the logs prefix for the destination index, which is already mentioned in the documentation as an index that users should avoid writing to due to pattern collisions. The reasons we decided not to use the logs index are summarized here.

[elasticsearchmachine]

Pinging @elastic/ml-core (Team:ML)

[CohenIdo]

Linting has resulted in changes to the comments:
./gradlew :x-pack:plugin:core:spotlessApply

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[SiddharthMantri]

Looks good - since logs-* is a known collision pattern https://www.elastic.co/guide/en/elasticsearch/reference/current/index-templates.html

[SiddharthMantri]

For indices not owned by Kibana, the kibana_system user should only have read privileges. security_solution-* falls under that pattern.

Can you please provide any additional information on why the elevated privileges are needed? I can then raise it with the KB security team.

[CohenIdo]

The Transform we're adding in the corresponding PR reads from the logs-wiz.vulnerability-default index and writes the result to the security_solution-wiz.vulnerability_latest-v1 index. This index is created in Kibana after the integration installation, which is why these privileges are necessary.

We've implemented the same logic for our native integration for the same reason—creating an index via the Transform, as shown here.

[slobodanadamovic]

@CohenIdo Could you please add corresponding test for security_solution-wiz.vulnerability_latest-* and logs-wiz.vulnerability-*" in ReservedRolesStoreTests#testKibanaSystemRole method?

[CohenIdo]

This new index I added, security_solution-wiz.vulnerability_latest, is used by the cloud security solution, this is the reason it was added under the same test case.

[CohenIdo]

@CohenIdo Could you please add corresponding test for security_solution-wiz.vulnerability_latest-* and logs-wiz.vulnerability-*" in ReservedRolesStoreTests#testKibanaSystemRole method?

Done:)

[slobodanadamovic]

Looks good from es-security side 👍

[SiddharthMantri]

Hey @CohenIdo

After having discussed this with the KB team, we've got a few questions -

• Given that the result needs to be written to security_solution...., can this be granted just index and create_index? If it does require the other two privileges, can you clarify why and add that to the PR description?
• Do we have any user facing docs that specify that users should not be writing to this index due to pattern collisions like we have here: https://www.elastic.co/guide/en/elasticsearch/reference/current/index-templates.html?

We try to be quite restrictive for kibana_system privileges to prevent any exploits should credentials or configs be compromised.

[CohenIdo]

Given that the result needs to be written to security_solution...., can this be granted just index and create_index? If it does require the other two privileges, can you clarify why and add that to the PR description?

It's a good point, I will test that with those privilege, I guess you right and we can use just index and create_index

Do we have any user facing docs that specify that users should not be writing to this index due to pattern collisions like we have here: https://www.elastic.co/guide/en/elasticsearch/reference/current/index-templates.html?

Our PMs probably will be able to help here @smriti0321 @tinnytintin10

[CohenIdo]

Given that the result needs to be written to security_solution...., can this be granted just index and create_index? If it does require the other two privileges, can you clarify why and add that to the PR description?

@SiddharthMantri, from the transform docs:

Elasticsearch API user
To manage transforms, you must meet all of the following requirements:
- create_index, index, manage, and read index privileges on destination indices. If a retention_policy is configured, delete index privilege is also required on the destination index.

[smriti0321]

Thanks for the catch on doc update @SiddharthMantri and @CohenIdo , I will work on this along with our documentation team. @benironside do you know who will be able to help with the updates on this page- https://www.elastic.co/guide/en/elasticsearch/reference/current/index-templates.html?

Also, we will introduce the change closer to GA of this feature. @CohenIdo

[CohenIdo]

./ci

[SiddharthMantri]

Hey @CohenIdo ! So after consulting with the team, I think we are good now. It's not super apparent from the PR, but we'd like to know why the source and destination index can't be the same one? Something like this:

elasticsearch/x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authz/store/KibanaOwnedReservedRoleDescriptors.java

Lines 357 to 383 in afd4bf4

	// For destination indices of the Threat Intel (ti_*) packages that ships a
	// transform for supporting IOC expiration
	RoleDescriptor.IndicesPrivileges.builder()
	.indices("logs-ti_*_latest.*")
	.privileges(
	"create_index",
	"delete_index",
	"read",
	"index",
	"delete",
	"manage",
	TransportIndicesAliasesAction.NAME,
	TransportUpdateSettingsAction.TYPE.name()
	)
	.build(),
	// For source indices of the Threat Intel (ti_*) packages that ships a transform
	// for supporting IOC expiration
	RoleDescriptor.IndicesPrivileges.builder()
	.indices("logs-ti_*.*-*")
	.privileges(
	// Require "delete_index" to perform ILM policy actions
	TransportDeleteIndexAction.TYPE.name(),
	// Require "read" and "view_index_metadata" for transform
	"read",
	"view_index_metadata"
	)
	.build(),

[CohenIdo]

Hey @CohenIdo ! So after consulting with the team, I think we are good now. It's not super apparent from the PR, but we'd like to know why the source and destination index can't be the same one? Something like this:

Good Idea @SiddharthMantri , I changed the index pattern to match any future integration we are going to add.
Instead security_solution-wiz.vulnerability_latest-* I am using now security_solution-*.vulnerability_latest-*

[SiddharthMantri]

LGTM! After discussing with @CohenIdo, we now know why the name pattern was added. Thank you for your patience! Can we add the summary from the discussion behind the naming to the PR description?