GreyNoise Executive Dashboard

Overview

Firewall and VPN logs record every connection, including the mass scanning that hits every internet-facing organization. Sorting that volume by hand is slow, and a successful login or an allowed inbound session can sit in the same stream as background noise.

The GreyNoise Executive Dashboard, added in version 3.1.0 of the GreyNoise App for Splunk, places that traffic next to GreyNoise Internet Scanner Intelligence. It is built for two audiences at once: an executive summary of how much traffic GreyNoise can classify, and a SOC triage view of the outcomes that need a person — allowed inbound sessions from malicious sources, internal hosts reaching malicious infrastructure, and VPN logins from addresses already in the GreyNoise dataset.

The dashboard reads a local copy of GreyNoise indicators. Each panel looks up the external address in the greynoise_indicators KV store that the Feed import maintains.

Prerequisites

Confirm the following before opening the dashboard:

Tools and Access

Setup

Step 1: Enable the Indicator Feed

The dashboard can only classify an address that is already in greynoise_indicators.

1. In Splunk, open Apps > GreyNoise App for Splunk > Configuration > Feed Configuration.

2. Select Enable Feed Import.

3. Set Feed Selection to All Indicators - Last 24 Hours.

   The default selection is benign indicators only. Malicious and suspicious matches appear only after the feed includes those classifications. All Indicators is the selection that fills every classification on this dashboard.

4. Select Force Feed Run Now so the first import starts immediately, instead of waiting for the daily run at 03:00.

5. Click Save.

The scheduled search greynoise_feed refreshes the lookup every day at 03:00. greynoise_feed_purge removes indicators whose last_seen is older than 7 days. An address GreyNoise has not observed inside that window is treated as unseen on the dashboard, even if it appeared in an older feed.

Include Community Dataset adds community workspace results to the same lookup. Leave it off unless those results should be part of the verdicts on this dashboard.

The panels read the KV lookup. Writing the same feed into a Splunk index is a separate option on Feed Configuration and is only needed when you also want those indicators in an index.

Step 2: Point the Dashboard at Your Logs

Two macros select the events the dashboard searches. Both ship pointed at Palo Alto Networks logs.

To retarget them:

1. Go to Settings > Advanced search > Search macros.
2. Set the app context to GreyNoise App for Splunk (SA-GreyNoise).
3. Open gn_fw_index and gn_vpn_index and replace the default search with the index and sourcetype that hold your logs.

Example for firewall logs that are not Palo Alto:

index=firewall sourcetype=cisco:asa

The firewall macro gn_fw_scope then decides direction from src_ip and dest_ip:

Internal means RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), IPv6 unique-local (fc00::/7), or link-local (fe80::/10, fec0::/10). Traffic that is internal-to-internal or external-to-external is left out of the classification, map, and triage panels.

The external address is the one matched to GreyNoise: the source on inbound traffic, and the destination on outbound traffic. An event counts as allowed when action is allow, accept, pass, or permit.

If your logs use different field names, add field aliases for src_ip, dest_ip, and action, or edit the gn_fw_scope and gn_vpn_scope macros so they read the names your sourcetype already extracts.

VPN status is taken from the first populated field among status, auth_status, result, and action. Values that match success or allow are treated as a successful login. Values that match fail, denied, or error are treated as a failure.

Step 3: Open the Dashboard and Confirm Data

1. Open Apps > GreyNoise App for Splunk.
2. Select GreyNoise Executive Dashboard.

The first panel under the introduction is Data Source Detector. It always searches the last 24 hours, independent of the time-range picker, and lists each index and sourcetype returned by gn_fw_index and gn_vpn_index.

NO DATA means the macro is pointed at the wrong index or sourcetype, or those logs have not arrived in the last day. Fix that before reading the panels below it.

Dashboard Controls

The controls at the top apply to the firewall panels. VPN panels always use the full VPN sourcetype for the selected time range.

Reading the Dashboard

Executive Summary

These five values sit on one row. Counts turn amber or red once they leave zero, except Malicious Traffic Rate, which uses the thresholds below.

Traffic Composition

Traffic by GreyNoise Classification is a donut of inbound and outbound firewall events, using the Direction control.

Traffic by GreyNoise Classification over Time is the same breakdown as an hourly line chart. The Y-axis is logarithmic, because malicious volume is usually far smaller than unseen traffic. Read the slope, not the height, when comparing classifications.

This timeline is the heaviest panel on the page. It looks up GreyNoise for each address in each hour. If it is slow, shorten the time range.

Where the Malicious Traffic Comes From

These panels keep only events whose external address is classified malicious.

VPN Authentication

VPN panels use gn_vpn_index and the same indicator lookup. They ignore the Direction, threshold, and regex controls. The panel titles say GlobalProtect because that is the default sourcetype. After you retarget gn_vpn_index, the same panels show whatever VPN logs that macro returns.

GlobalProtect VPN Logins by Severity assigns each authentication attempt a tier:

A successful login from an address that is absent from the feed is not given a tier.

GlobalProtect VPN — Successful Logins from Malicious Sources lists the P1 events: time, source IP, user, GreyNoise actor, ASN, and country. The title on the panel refers to GreyNoise sources in the feed. Click a row to open that IP in the GreyNoise Visualizer.

Treat every P1 row as a completed login from infrastructure GreyNoise has already observed. Confirm the account, the source address, and whether that login was expected.

SOC Triage Tables

The event detail table is a recent sample. The search keeps the newest 20,000 firewall events in the time range, keeps the malicious matches, applies the Regex Filter, and displays at most 1,000 rows. Use a shorter time range or a tighter regex when you need a specific slice of that activity.

Understanding the Output

Work the page from the summary row down.

1. Data Source Detector should show OK for the firewall sourcetype, and for the VPN sourcetype if you use those panels. A feed that has not run yet leaves every address unseen, and the malicious panels stay at zero.
2. Malicious Traffic Rate answers how much of the perimeter traffic GreyNoise currently classifies as malicious. A low rate is normal. The number is the share of events, so a handful of allowed malicious sessions can still matter when the rate looks small.
3. P1 VPN logins and Allowed Inbound Traffic from Malicious Sources are the two outcomes that already crossed a control: a login completed, or the firewall allowed the session.
4. Internal Hosts Reaching Malicious Infrastructure flips the view. These are assets inside the network opening connections to destinations in the malicious feed.
5. The organization, country, and event-detail panels explain who those addresses are. Actor, ASN, and the Visualizer link are the handoff into investigation.

Raising the Inbound or Outbound Threshold hides one-off connections and keeps the hosts and sources with repeated contact. Lower them when you want the first occurrence.

Benefits for the SOC Team

• One page for leadership and triage. Volume, classification mix, and the highest-severity outcomes are on the same dashboard as the IP, host, and account detail an analyst needs next.
• No per-panel API lookups. Verdicts come from the feed lookup, so analysts can change the time range and filters without spending API quota.
• Allowed traffic is separated from blocked scanning. The allowed-inbound count and the top-sources table are limited to sessions the firewall accepted from a malicious address.
• Outbound contact is called out on its own. Internal hosts talking to malicious destinations are counted and listed separately from inbound scanning.
• VPN successes from known GreyNoise addresses are a single number. P1 is the count of completed logins whose source is already in the indicator feed, with the account and source on the row beneath it.

Conclusion

The Executive Dashboard is the view of record for how GreyNoise classifications line up with firewall and VPN activity already in Splunk. Once the feed is importing all indicator classifications and the two index macros point at your logs, the summary row shows whether malicious traffic is reaching assets or leaving the network, and the tables underneath name the addresses, hosts, and accounts involved.

The use case guides that follow turn those same questions into scheduled detections.