Build Security Hub custom insight configurations with finding filters and group-by attributes.
Build Security Hub custom insight configurations with finding filters and group-by attributes.
Required Fields
NameFiltersGroupByAttributeOutput will appear here...Build a Security Hub custom insight, a saved finding filter plus a GroupByAttribute that turns raw findings into a grouped, trackable metric (like 'critical findings grouped by account') rather than a flat, unsorted findings list. Filters compose as an implicit AND across different filter keys (SeverityLabel AND WorkflowStatus AND ProductName), but within a single key the listed values act as an OR, so the example's WorkflowStatus matching both NEW and NOTIFIED returns findings in either state, not findings that are somehow both simultaneously.
OR within a key, AND across keys. The example's WorkflowStatus listing both NEW and NOTIFIED matches findings in either state (OR), while requiring SeverityLabel CRITICAL and RecordState ACTIVE and WorkflowStatus in that OR set are all required together (AND). Getting this backwards is a common cause of an insight returning zero results when the filter combination is logically impossible under the actual AND/OR semantics.
Only display and aggregation, GroupByAttribute doesn't filter findings further, it determines how the matched findings are bucketed and counted in the insight's summary view (by account, by resource type, by finding type, etc.). Two insights with identical Filters but different GroupByAttribute values return the same underlying finding set, just organized differently.
Not directly, an insight itself is a saved, groupable view for human triage and dashboards, not an event source. For automated response to matching findings, you'd build a separate EventBridge rule against Security Hub's finding-generated events using an equivalent filter pattern, the insight and the automation rule are two different mechanisms that happen to share similar filter logic.
The builder validates that Name, Filters, and GroupByAttribute all resolve before accepting the JSON as a valid CreateInsight request, the three fields the Security Hub API requires; it doesn't validate that your specific filter key/value combinations will actually match any real findings, since that depends on what's live in your Security Hub finding store.
An insight filter combination that looks reasonable on paper can still return zero results if the AND-across-keys, OR-within-key logic doesn't match what you intended, test a new insight against known findings before relying on its count in a dashboard.
GroupByAttribute choices like ResourceType or AwsAccountId are far more actionable for triage prioritization than the default ungrouped view, but an insight grouped by a high-cardinality attribute (like ResourceId) produces an unwieldy number of tiny groups rather than a useful summary.
Insights don't retroactively apply to findings generated before the insight was created in a special way, they query the same underlying finding store as everything else, so an insight is really just a saved, reusable filter+group query, not a forward-only tracking mechanism.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.