TL;DR: Internet scanning is deliberate, enumerable activity rather than ambient background noise, and GreyNoise founder Andrew Morris argues that defenders can baseline it across major cloud regions and strip it from logs, according to Sprocket Security. The real value is not just cleaner telemetry but better attribution, because noisy traffic and hostile reconnaissance often look the same until governance, filtering, and context are applied.
NHIMG editorial — based on content published by Sprocket Security: an interview with Andrew Morris, Founder and Chief Architect at GreyNoise Intelligence, on internet scanning and signal filtering
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: How should security teams reduce internet scan noise without missing real threats?
A: Teams should baseline known scanner behaviour across cloud regions, then suppress recurring benign sources in SIEM and detection workflows.
Q: Why does internet-wide reconnaissance matter for IAM and NHI programmes?
A: Reconnaissance often finds the weakest identity surfaces first, including service accounts, API keys, OAuth-connected apps, and exposed admin endpoints.
Q: What do teams get wrong about background internet scanning?
A: They treat it as unavoidable noise instead of a measurable behaviour set with identifiable patterns.
Practitioner guidance
- Build a live scan baseline across major cloud regions Deploy sensors or read-only data feeds in AWS, Azure, Google Cloud, and key regional networks so you can identify recurring scan sources and suppress them consistently in SIEM workflows.
- Classify scan traffic with observable trust signals Use reverse DNS, user-agent patterns, response to opt-out requests, and request cadence to distinguish legitimate crawlers from hostile reconnaissance before tuning detections.
- Tune SIEM rules to preserve identity-relevant anomalies Remove known internet-wide noise from alert pipelines, then prioritise events tied to abnormal credential use, exposed APIs, token abuse, and unusual service account behaviour.
What's in the full article
Sprocket Security's full article covers the interview detail this post intentionally leaves for the source:
- GreyNoise-style methods for building a definitive list of internet scanners across cloud regions and providers
- Practical examples of using reverse DNS, user agents, and opt-out handling to separate legitimate scanning from hostile activity
- Operational guidance on when sensor networks should be rebuilt, burned, or redeployed after fingerprinting
- Additional interview context on how practitioners should think about internet-wide observation as an ongoing program
👉 Read Sprocket Security's interview on filtering internet background noise and scanner attribution →
Internet scan telemetry: what it means for SOC teams?
Explore further
Internet-wide scanning is a governance issue because defenders cannot manage what they cannot classify. The article's central point is that background noise is actually observable attacker and researcher behaviour, which means security teams need policy, not intuition, to decide what gets suppressed, escalated, or retained. In identity-heavy environments, that classification layer should explicitly account for service accounts, API keys, and OAuth-connected applications. The practitioner conclusion is simple: telemetry governance belongs in the same conversation as access governance.
A question worth separating out:
Q: What should organisations do when sensor infrastructure is discovered or burned?
A: They should expect rebuild cycles and automate redeployment rather than protecting sensors as fixed assets. Observation points are part of the control plane, so resilience depends on quick replacement, coverage across providers, and a process for restoring baseline visibility without long downtime.
👉 Read our full editorial: Internet scan telemetry is a governance problem, not background noise