How do I check for unrestricted inbound exposure without approval in Splunk?

Run the published SPL query on this page against Splunk Enterprise / Enterprise Security. It reads index=cloud sourcetype=network:rules, approved_exposure_register.csv (lookup) and reports: Inbound rule permitting unrestricted source access with no current, unexpired entry in the approved exposure register.

NIST SP 800-53 Rev. 5 · System and Communications Protection

SC-7 on Splunk

Unrestricted inbound exposure without approval — a published SPL query you can run against Splunk Enterprise / Enterprise Security, with the evidence it needs, the settings you decide, and what a result does and does not establish.

Why this matters

A server left open to the entire internet without approval

Cloud systems make it trivial to open a service to the whole internet, often as a temporary measure during troubleshooting. Temporary frequently becomes permanent. Some public exposure is intended and legitimate, so a check that reports every open port is ignored within a week.

Why this check earns its place. It distinguishes deliberate, documented exposure from undocumented exposure, which is the distinction that makes the result actionable rather than noise.

What it reads: The organization's own firewall rules, compared against its register of approved exposures.
What it reports: Services reachable from anywhere on the internet with no unexpired approval on record.

See related public disclosures on the Signals page →

ControlSC-7 — Boundary Protection

PlatformSplunk (SPL)

SeverityCritical

ValidationLab-validated

What this finds

Inbound rule permitting unrestricted source access with no current, unexpired entry in the approved exposure register.

The requirement

The organization must monitor and control communications at the external managed interfaces to the system, and connect to external networks only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture.
NIST SP 800-53 Rev. 5 — SC-7 (Boundary Protection).

NIST requires controlled external interfaces. Which exposures are acceptable, for how long, and with what compensating controls is organization-defined — supplied here through the approved exposure register. Public exposure is not automatically wrong; undocumented or expired exposure is.

How this maps to the CISA performance goals

The Cross-Sector Cybersecurity Performance Goals are a voluntary baseline published by CISA — the U.S. federal agency for critical-infrastructure cybersecurity — written for organizations too small to employ security staff. This control speaks to:

3.S — Secure internet-facing devices
The goal is securing what faces the internet; the pack finds unrestricted inbound exposure that was never approved.
3.I — Implement logical/physical network segmentation
Unreviewed inbound paths are the boundary that segmentation is meant to impose.

See the full coverage map, including the goals no query can answer →

Evidence this query needs

Approved exposure register `approved_exposure_register.csv`

Records which internet-facing exposures have been formally accepted, with an expiry. Public exposure is not automatically wrong; undocumented or expired exposure is.

Minimum fields: resource_id, port, approved_source_cidr, expires_on

The expiry date is the field that makes this register meaningful. Without it, a one-time approval silently becomes permanent — which is the failure mode this control exists to catch.

The query

Published as sc-7-unrestricted-exposure.splunk.spl. Reads index=cloud sourcetype=network:rules, approved_exposure_register.csv (lookup). Requires: Search access to the cloud index; Read on the lookup.

Before this returns anything, index=cloud sourcetype=network:rules has to be reaching Splunk Enterprise / Enterprise Security, and approved_exposure_register.csv (lookup) has to be landed there. If not, the query reports nothing found — which looks exactly like nothing wrong. What has to be switched on first →

index=cloud sourcetype=network:rules
| where direction="inbound" AND action="allow"
| where source_cidr IN ("0.0.0.0/0","::/0","*","any")
| lookup approved_exposure_register.csv resource_id, port
    OUTPUT approved_source_cidr, expires_on, approver, compensating_control
| eval expiry_epoch=if(isnull(expires_on) OR expires_on="",
                       0, strptime(expires_on,"%Y-%m-%d"))
| eval approval_current=if(expiry_epoch>now(),1,0)
| where approval_current=0
| eval exposure=port."/".protocol." from ".source_cidr
| table resource_id, rule_name, exposure, port, protocol,
        source_cidr, expires_on, approver, source_system
| sort port

Open this pack on Splunk to adjust the settings and download it →

The interactive version opens on Splunk — the platform on this page — even if your environment profile does not list it.

Settings you decide

NIST states the objective and leaves these to your organization. The interactive version of this pack applies them to the query for you.

Limit to specific resources (optional): Paste resource identifiers, one per line.

What this query returned when it was run

Executed against Splunk Enterprise 10.4.2 on 2026-08-07 against purpose-built test data. The software examined 3 records and returned 1 result in 0.079 seconds.

resource_id	rule_name	exposure	port	protocol	source_cidr	source_system
sg-legacy-db	allow-mysql-any	3306/tcp from 0.0.0.0/0	3306	tcp	0.0.0.0/0	AWS Config

Test data, not a real organization. It shows the query executes and returns the intended shape of result.

Running it continuously

Correlation search → notable event

Search type:      Correlation search (Enterprise Security)
Cron schedule:    0 */2 * * *   (every 2 hours)
Time range:       -2d to now
Trigger:          Number of results > 0
Alert action:     Create notable event
Urgency:          Critical
Security domain:  Network
Drill-down:       index=cloud resource_id="$resource_id$"
Throttling:       Suppress 2h on resource_id, port

Computing an exposure string up front gives the analyst the whole picture in the notable title, without opening the event.

What a result does not prove

Unrestricted exposure is not automatically a vulnerability — public web tiers are meant to be public. What this check establishes is that the exposure is not currently covered by a documented, unexpired approval.

Validation status for this platform: Lab-validated. Executed by the maintainer in a personally controlled laboratory environment on the date shown. Table names, field names, and operator support still vary by tenant configuration, API version, connector, and add-on.

Before you act on a result

Is this a deliberate public service that simply has not been registered?
Has an approval lapsed rather than never existed?
What compensating controls sit in front of this exposure?
Can the source range be narrowed without breaking the service?

Common questions

How do I check for unrestricted inbound exposure without approval in Splunk?: Run the published SPL query on this page against Splunk Enterprise / Enterprise Security. It reads index=cloud sourcetype=network:rules, approved_exposure_register.csv (lookup) and reports: Inbound rule permitting unrestricted source access with no current, unexpired entry in the approved exposure register.
What permissions are needed to run this Splunk query?: Search access to the cloud index; Read on the lookup.
What evidence does SC-7 need that Splunk cannot produce?: Approved exposure register (approved_exposure_register.csv). Records which internet-facing exposures have been formally accepted, with an expiry. Public exposure is not automatically wrong; undocumented or expired exposure is. At minimum it must carry: resource_id, port, approved_source_cidr, expires_on.
Does a result from this query mean the control has failed?: Unrestricted exposure is not automatically a vulnerability — public web tiers are meant to be public. What this check establishes is that the exposure is not currently covered by a documented, unexpired approval.

Terms used on this page

NIST SP 800-53the U.S. federal catalogue of security requirements: The catalogue of security and privacy requirements published by the National Institute of Standards and Technology, a U.S. federal agency. U.S. government systems are measured against it, and many private organizations adopt it voluntarily. Each requirement has an identifier such as AC-2. Official source →
CISACybersecurity and Infrastructure Security Agency: The U.S. federal agency responsible for national critical-infrastructure cybersecurity. Its publications are works of the U.S. government and are free to use. Official source →
SPLSearch Processing Language: The language used to ask questions of data held in Splunk. A query written in it is text and can be read before it is run.
CPGCross-Sector Cybersecurity Performance Goals: A voluntary baseline of security practices published by the U.S. Cybersecurity and Infrastructure Security Agency, written specifically for organizations too small to employ security staff. It is a short, plainly written starting list rather than a full standard. Official source →
lab-validatedexecuted in a controlled test environment: The check has been run, by the maintainer, against real security software loaded with purpose-built test data, and what it returned was recorded. It has not been run on any real organization's data.

Every term this project uses →