Currently, CSE defines a set of standard Match Lists as a way to allow users to specify lists of Entities and other indicators that should affect whether or not Rules create Signals. However, starting next week, the Rules included with CSE will begin transitioning to leverage Entity tags for this purpose instead. Tags on Entities are more flexible and can also provide context to analysts during the investigation phase.
Next week, a new set of standard tag schemas will be introduced in CSE. These tag schemas will correspond to the existing standard Match Lists:
Key | Allowed Values | Equivalent Match List |
---|
_deviceGroup | admin | admin_ips |
awsAdmin | AWS_admin_ips |
business | business_ips |
gcpAdmin | GCP_admin_ips |
googleWorkspaceAdmin | Google_Workspace_admin_ips |
salesforceAdmin | salesforce_admin_ips |
sandbox | sandbox_ips |
scanTarget | scanner_targets |
_deviceService | dns | dns_servers dns_servers_dst dns_servers_src |
ftp | ftp_servers |
smtp | smtp_servers |
sql | sql_servers |
ssh | ssh_servers |
telnet | telnet_servers |
_deviceType | authServer | auth_servers auth_servers_dst auth_servers_src |
lanScanner | lan_scanner_exception_ips |
nms | nms_ips |
paloAltoSinkhole | palo_alto_sinkhole_ips |
proxyServer | proxy_servers proxy_servers_dst proxy_servers_src |
vpnServer | vpn_servers |
vulnerabilityScanner | vuln_scanners |
webServer | http_servers |
_networkType | guest | guest_networks |
nat | nat_ips |
vpn | vpn_networks |
_userGroup | awsAdmin | AWS_admin_users |
dsReplication | ds_replication_authorized_users |
gcpAdmin | GCP_admin_users |
googleWorkspaceAdmin | Google_Workspace_admin_users |
kerberosDowngrade | downgrade_krb5_etype_authorized_users |
salesforceAdmin | salesforce_admin_users |
(There are five standard match lists not affected by this change, as they do not contain Entities. These include: business_asns, business_domains, business_hostnames, threat, and verified_uri_paths.)
Beginning Thursday, October 20, the contents of the standard match lists listed above will automatically be copied to tags set on the individual entities. So, for example, if an Entity 1.2.3.4
is in match list sql_servers
, a tag _deviceService:sql
will be set on it. CSE will continue to automatically create these tags from the standard match lists for a period of 3 months, until January 20, 2023. During this period, pre-defined rules will be updated to reference these tags instead of the standard match lists, so by the end of this period all rules will be updated and CSE will no longer automatically create these tags.
Please update any process you use to maintain the members of standard match lists by January 20, 2023 to maintain standard Entity tags instead (or in addition). We highly recommend you take advantage of Entity Groups to set Entity tags rather than individually setting tags. Entity Groups enable the automatic application of attributes like tags based on the Entity's value, IP address range, or inventory group.
Note that you cannot extend the standard tag schemas (for example, you cannot add a value azureAdmin
to _userGroup
). (The underscore prefix in the schema name means it's a system-defined schema.) Instead, create a different tag schema (such as customUserGroup
) with such extended values.
You can refer to Entity tags in Rule expressions. For example, if you've attached the tag _deviceService:sql
to an Entity, this statement will return "true" if that Entity is listed in a Record's srcDevice_ip
field:
array_contains(fieldTags["srcDevice_ip"], "_deviceService:sql")
Additional information about the standard tag schema, match lists, Entity groups, and using these features with Rules is available in the Cloud SIEM Documentation.
Minor Changes and Enhancements
- [New] Users can now filter object lists based on tag schema. The list results will include all objects that have a tag that are part of that schema. For example, if you search for
_networkType
(from the note above) the list results will include any object that has a tag of _networkType:guest
, _networkType:nat
, and/or _networkType:vpn
.
Resolved Issues
- Entity relationships were not taking sensor zones into account properly.
- Entity details pages were only briefly displaying the proper Criticality.
- The Entities Count links on the Entity Criticality list pages were pointing at the wrong URLs.