Network Security
Attack Surface
Inventory every exposed asset, service, and credential in TechPulse's environment so you can see exactly what an attacker sees before they do.
The Company That Did Not Know It Owned 73 Servers
In 2019, a penetration testing firm was hired to assess a mid-size e-commerce company's security posture. The client provided a scope document listing their known assets: 12 production servers, 3 staging environments, and a handful of internal tools. The pentesters found 73 internet-reachable servers belonging to that organization — the remaining 61 were forgotten test instances, deprecated APIs, acquired-company infrastructure that never got decommissioned, and a VPN endpoint that IT believed had been shut down eighteen months earlier.
Eleven of those forgotten assets had critical vulnerabilities. Three had already been compromised by unknown parties before the engagement began. The client had been defending a map that bore almost no resemblance to their actual territory.
This is the attack surface problem — and it is far more common than anyone wants to admit. You cannot protect what you do not know exists. And in modern organizations, the gap between "what IT thinks is out there" and "what is actually exposed" tends to grow faster than anyone tracks it.
What Attack Surface Actually Means
An attack surface is the complete set of points where an unauthorized actor could attempt to interact with a system — every exposed port, every public-facing service, every credential that could be phished, every API endpoint that accepts external input, every employee laptop that connects from a coffee shop. If an attacker can reach it and do something to it, it is part of the attack surface.
The concept has three dimensions. The digital attack surface covers all the networked assets: servers, services, APIs, cloud resources, domain names, and the software running on all of them. The physical attack surface covers locations where physical access could lead to digital compromise: server rooms, unattended workstations, unlocked network closets, USB ports. The human attack surface covers every person with credentials or access — employees, contractors, vendors, and anyone who could be socially engineered into handing over access.
Most security programs focus heavily on the digital surface because it is the most measurable. But the most effective attacks often enter through the human surface and then traverse the digital one. A phishing email that harvests an engineer's VPN credentials does not need to touch a single exposed port — it walks straight through the front door.
Network Exposure
Every IP address and port reachable from outside the organization's controlled perimeter. Includes production services, management interfaces, legacy endpoints, cloud assets, and any device with a public IP. This is what automated scanners find within minutes of a new service going live.
Software & Code
Every application, library, dependency, and framework that processes external input. Each one carries a version number, a CVE history, and a configuration that may or may not match its hardened defaults. A single outdated npm package in a build dependency can introduce a critical vulnerability into a production service.
Credentials & Identity
Every username, password, API key, certificate, SSH key, and service account that can authenticate to a system. Leaked credentials from third-party breaches, hardcoded API keys in public repositories, and service accounts with excessive permissions are among the most reliable entry points an attacker can find.
Third-Party & Supply Chain
Every vendor, SaaS tool, managed service provider, and open-source dependency that has access to the organization's data or infrastructure. Each integration extends the attack surface beyond the organization's direct control — and the security of the weakest vendor becomes a floor on the organization's overall posture.
How Attackers Map Your Surface Before You Do
Before launching any attack, skilled adversaries conduct reconnaissance — a systematic effort to understand the target's attack surface from the outside, using only publicly available information and passive or semi-passive scanning. The goal is to build a picture of what exists, what version it is running, and what the most promising entry points look like. This happens before any exploit is launched.
How an Attacker Maps a Target's Surface
Passive OSINT collection — LinkedIn reveals employee names, roles, and email formats. Job postings expose technology stack ("experience with AWS, Kubernetes, PostgreSQL required"). GitHub repositories may contain hardcoded credentials, internal hostnames, or infrastructure-as-code files describing the network layout.
DNS enumeration — querying public DNS records reveals subdomains (mail.techpulse.com, vpn.techpulse.com, staging-api.techpulse.com), mail server identities via MX records, and sometimes internal infrastructure through misconfigured zone transfers. Tools like dnsx and Subfinder automate this in minutes.
Port scanning & service fingerprinting — scanning the organization's IP ranges to identify open ports and the services behind them. Banner grabbing retrieves version strings from services that advertise themselves. Shodan passively indexes this data for billions of internet-connected devices so attackers do not even need to send a single packet to the target.
Vulnerability correlation — once service versions are known, attackers cross-reference them against the CVE database and public exploit repositories like Exploit-DB. If the target is running Apache 2.4.49, the attacker already knows exactly which public exploit applies and what it achieves.
Credential exposure checking — services like Have I Been Pwned aggregate credentials from thousands of public breaches. An attacker searches for the target's email domain in these databases and retrieves any matches — then tests those credentials against the company's VPN, webmail, or SSO portal using automated tools.
Shodan: The Attacker's Search Engine
Shodan continuously scans the entire public internet and indexes what it finds — open ports, service banners, TLS certificates, device types, and geographic locations. An attacker can query Shodan for org:"TechPulse" and get a current inventory of every internet-facing asset associated with the company's registered IP ranges, complete with software versions and open ports — without sending a single packet to TechPulse's infrastructure. Security teams use Shodan to see what attackers see. If something appears there that should not be public, it needs to be addressed immediately.
The uncomfortable reality is that a motivated attacker can build a detailed map of an organization's attack surface in a matter of hours using only free, publicly available tools — and they will often know more about what is exposed than the organization's own IT team. The answer is not to panic. It is to run the same reconnaissance on yourself first, regularly, and use the findings to drive your remediation priorities.
Attack Surface vs Attack Vector: A Critical Distinction
These two terms get used interchangeably in casual conversation, but they mean different things and the distinction matters for how you prioritize defenses. The attack surface is the collection of all possible entry points — the total landscape of what could be targeted. An attack vector is the specific path an attacker actually uses to exploit one of those entry points.
Reducing the attack surface means eliminating or hardening exposure points before attackers find them. Every service shut down, every port closed, every default credential changed, and every unnecessary permission revoked makes the attack surface smaller. But surface reduction has limits — a web application that serves customers cannot simply stop being accessible. That is where controls on the attack vectors themselves become necessary.
Shadow IT: The Surface You Do Not Control
Shadow IT refers to systems, services, and applications in use within an organization that the IT or security team does not know about and has not approved. It is not inherently malicious — it almost always starts with a well-meaning employee solving a real problem faster than the official process would allow. A marketing manager signs up for a new analytics platform and connects it to the Google Analytics account using their corporate credentials. A developer spins up an EC2 instance under their personal AWS account to test something quickly. An ops engineer sets up a Slack bot with access to production logs to make troubleshooting easier.
Each of these decisions creates exposure the security team cannot see, cannot monitor, and cannot patch. The analytics platform may retain corporate data without appropriate DPA agreements. The EC2 instance may have permissive security groups that were "just for testing." The Slack bot may store production log snippets in a SaaS vendor's infrastructure with no data retention controls.
TechPulse: Meera Discovers the Shadow Stack
During her first attack surface audit, Meera ran a search across TechPulse's OAuth app authorizations — the list of external applications that employees had granted access to their corporate Google Workspace accounts. She found 47 third-party applications with varying levels of access. Twelve had full mailbox read permissions. Three had been authorized by employees who had since left the company and whose accounts had been deactivated — but the OAuth tokens remained valid, meaning those applications could still pull email data. One application in the list had been acquired by a different company six months earlier and had changed its privacy policy. None of this had been reviewed. Revoking the unnecessary authorizations took two hours. Finding them took a single query. Not finding them would have taken one well-timed breach to matter.
The GitHub Secret Problem Is Worse Than You Think
Research published by GitGuardian found over 10 million secrets — API keys, passwords, private keys, and tokens — exposed in public GitHub repositories in a single year. Automated bots scan every public commit within seconds of it being pushed, harvesting credentials before the developer who accidentally included them even notices. Deleting the file in a follow-up commit does not help — the secret is still visible in the git history. The fix requires rotating the credential immediately upon discovery, then scrubbing the git history — which requires rewriting it, force-pushing, and coordinating with every collaborator. Secret scanning tools integrated into the CI/CD pipeline catch these before they reach the public repository.
Attack Surface Management: Making the Invisible Visible
Attack Surface Management (ASM) is the ongoing practice of discovering, inventorying, and monitoring an organization's external-facing assets — continuously, not just during annual assessments. The "continuously" part is what separates effective ASM from a spreadsheet that gets outdated within a week of being created.
Reactive Asset Inventory
A point-in-time snapshot produced during annual audits or penetration tests. Accurate on the day it is produced, degrading steadily as new services are deployed, cloud resources are spun up, and employees connect unauthorized tools. Most organizations know this model is insufficient but have not yet replaced it.
The gap: a new EC2 instance with a public IP and default security groups goes undetected for the eleven months between assessments.
Continuous Attack Surface Management
Automated discovery that continuously monitors internet-facing assets, detects new exposures within hours of them appearing, and alerts the security team when something unexpected shows up. Tools like Censys, Runzero, and the enterprise offerings from CrowdStrike and Microsoft integrate ASM data into the broader security operations workflow.
The standard: any new asset reachable from the internet triggers an alert within 24 hours — no exceptions, no manual review required to catch it.
A mature ASM program answers four questions continuously: what assets do we own, what is running on them, what vulnerabilities do they carry, and which of those vulnerabilities are being actively exploited in the wild right now. The last question is where threat intelligence from Lesson 2 feeds directly into the prioritization — a vulnerability with a CVSS score of 7.5 that is not currently being exploited gets different treatment than a 6.0 vulnerability that every ransomware group discovered last Tuesday.
The Principle of Least Exposure
Every service, port, and permission should exist only if it is required for a specific, documented business purpose — and should be scoped as narrowly as that purpose allows. An internal admin panel does not need to be reachable from the public internet. An API key used for read-only reporting does not need write permissions. An employee in Marketing does not need access to the production database. Every unnecessary exposure removed is an attack vector permanently eliminated. This principle has a companion in system hardening — Lesson 16 covers it in detail — but it starts here, in how you think about what should be exposed in the first place.
TechPulse's Surface Reduction Plan
After running her first full attack surface audit — combining external scanning from a Shodan-like perspective, internal asset discovery, DNS enumeration of all known subdomains, and the OAuth authorization review — Meera produced a prioritized remediation list organized by risk level. Not by difficulty, not by team ownership, but by the combination of exposure severity and likelihood of exploitation.
The top five items on her list: a forgotten staging environment running an unpatched version of the application server reachable on a public IP; an RDP port (3389) open to the internet on a Windows server in the co-location facility; three API keys in a public GitHub repository committed by an engineer who had since left; 23 OAuth tokens from departed employees still active; and a VPN endpoint running a version of OpenVPN with a known authentication bypass.
None of these were the result of malice. All of them were the natural accumulation of a company growing faster than its security practices. And all of them were exactly what an opportunistic attacker scanning for low-effort entry points would have found within an afternoon. The staging environment was decommissioned that day. The RDP port was restricted to VPN-only access. The API keys were rotated within the hour of discovery. The OAuth tokens were revoked in bulk. The VPN was patched that weekend.
Attack surface management is not a project with an end date. It is a continuous discipline — because the surface keeps changing every time someone deploys a new service, spins up a cloud resource, or connects a new tool. The organizations that stay ahead of it are the ones that have made discovery and inventory a part of how they operate, not something they do when they have time.
Quiz
1. A TechPulse Content team member signed up for a cloud-based video editing platform and connected it to the corporate Google Drive to access project assets. IT was never informed. The platform now has OAuth access to the entire shared drive. Which attack surface category does this represent?
2. Meera discovers a TechPulse production database API key was accidentally committed to a public GitHub repository four days ago. Automated bots are known to scrape new commits within seconds. What is the correct first response?
3. TechPulse's Engineering team deploys new cloud services several times per week. Meera wants to ensure any new internet-facing asset is detected within 24 hours regardless of who provisioned it or whether they notified IT. Which approach best meets this requirement?