Underground Security: Vegas's Underground Tunnels as a Model For Attack Surface Reduction
Last month, I was in Las Vegas for Defcon 32. And like many attendees, I was navigating the Las Vegas Convention Center for the first time. That is where I first encountered the Vegas Loop.
Picture this: You are trekking through acres of Las Vegas parking lots, the black asphalt radiating the sweltering August heat. Ahead, you see a stairway leading underground. Could this be a mirage, or is it the portal to hell itself?
As you descend the stairs, you encounter an underground room that feels semi-familiar, like a subway station. But instead of hearing the expected rumble of subway cars, there's nothing but the noises of Tesla electric cars appearing and then quietly whisking passengers into the lighted, circular tunnels.
The Vegas Loop - tunnels under the city
These Teslas have human drivers behind the wheels today. But the Vegas Loop is an example of Attack Surface Reduction (ASR). It is easy to see how this model could enable a future of safe autonomous vehicles. And it has practical lessons you can use to reduce security risks in novel ways.
ASR Reduces Risk
Attack Surface Reduction isn't about making systems smaller or simpler. It's about smart design choices that eliminate vulnerabilities before they can be exploited. It's the security equivalent of choosing to fight your battles on favorable terrain.
The goal is to reduce exposure to attack. In the early days of computing, ASR was as simple as closing unnecessary ports or disabling unused services. But as our product architectures have grown more complex, so too has the discipline of ASR. Microsoft's Security Development Lifecycle (SDL) brought ASR to the forefront of threat modeling, solidifying it as a fundamental principle of secure design.
In the surface world, autonomous vehicles grapple with a complicated mess of variables: unpredictable pedestrians, cyclists, surprise construction zones, and the ever-present threat of human error from other drivers.
However, in the controlled environment of the Vegas Loop, many of those threats vanish, as if Thanos had snapped his fingers. By moving these vehicles underground, they have created an environment friendly to autonomous vehicles through a creative application of attack surface reduction. The move eliminated the chaos, leaving behind a simplified, predictable environment where autonomous vehicle can safely operate in the future. The vehicles I rode in were all human-operated, but they plan to move to a fully autonomous mode in the future.
The Vegas Loop isn't the only place where ASR is applicable. Let's explore a few more examples that showcase the advantages of this approach:
Drone Deliveries: Imagine a drone, loaded with your latest online purchase, descending into your backyard. Sounds convenient, right? But it's also a pandora's box of safety concerns. Pets, children, clotheslines, and even that inflatable pool you set up yesterday all become potential hazards. Some drone delivery operators are sidestepping these risks entirely. One lowers packages from a safe height using a crane system, while another employs miniature parachutes. By avoiding the "last mile" descent altogether, they've dramatically reduced their attack surface.
Autonomous Trucking: Long-haul trucking seems ripe for automation, but navigating city streets presents significant challenges. One company's solution is to create shipping depots near interstate highways. Their autonomous trucks stick to the predictable environment of the freeway, while human drivers handle the complex "last mile" in urban areas. It's a smart compromise and example of ASR.
Each of these examples embodies the core principle of ASR: don't just manage risks—eliminate them entirely wherever possible.
Unfortunately, many engineers fail to perform ASR, and therefore miss one of the best opportunities to secure their products. Here are 3 reasons people fail to do this important work:
Timing: All too often, threat modeling and design analysis happen too late in the development cycle. By the time security teams get involved, major architectural decisions have been set in stone, leaving little room to make meaningful impact.
Career Fear: Pushing back against product requirements can feel like a career-limiting move in some cultures. Many engineers hesitate to challenge decisions made higher up the chain, even when there are clear security issues.
Complexity = Confusion: Complex architectures make it difficult to understand the attack surface. With numerous interconnected components and third party systems, understanding the full attack surface can leave engineers feeling helpless.
Fortunately, there is a path forward. I'm going to explain how you can address each of these 3 challenges with actionable steps.
Let's dive in.
Step 1: Cultivate Security Champions
Shift-left efforts sometimes fall short, leaving security teams scrambling to perform last-minute reviews before launch. At that point, it can be difficult to impact the product in meaningful ways. When this happens, focus on building relationships with the teams and people who can pull you into design conversations earlier. Here is a list of teams to jump start your list:
Product Management - The product team can help identify security concerns during the initial business requirements phase.
Legal - The legal team is often brought in earlier than security teams. They can help identify security concerns while evaluating legal risk and pull you in.
Privacy - The privacy team can help pull you in when there is personal data that needs protection.
PMO - The PMO team knows the schedule inside and out. They can pull you in at the right times but they don't like to be surprised with new requirements. Communicate early and often.
Procurement - New vendors mean new risks. Procurement can be your gatekeeper, insisting on security reviews before signing contracts.
To make it easy for these teams to include you:
Clearly communicate your mission, vision, and strategy. Help them understand that early intervention leads to easier, cheaper fixes.
Empower them to identify security red flags. Provide a short list of questions they can use to spot security concerns.
Be accessible. Provide a single point of contact or easy-to-use intake form. Remember, if it's not easy, it won't happen.
Teach them to ask the tough questions: Do we really need to store social security numbers? Does that new vendor really need full access to the entire customer database? By asking the tough questions early, you can often reduce the attack surface before it forms.
Step 2: Disagree and Commit
One of Amazon's leadership principles is, disagree and commit. Like most of Amazon's leadership principles, it has tension built in. Disagree and commit are opposites. Here's where it matters when pushing back or disagreeing about product designs.
When you see security red flags in designs, you have a responsibility to speak up. Your customers are counting on you to have a backbone and speak up. They are counting on you to be their advocate.
But the way you disagree is important:
Do it with data and evidence rather than hyperbole and hearsay.
Don't just point out issues—offer solutions. Show them what a more secure design could look like.
If the business makes a decision to proceed despite your concerns, be prepared to commit—but do so strategically.
Committing doesn't mean giving up. There's an effective way to commit. There are a few anti-patterns you should avoid:
Don't actively sabotage the decision.
Don't wash your hands and walk away.
Don't spread negativity and blame.
Instead, have a Plan B ready. The goal is to reduce the risk as much as possible. This might include implementing additional WAF rules, improving monitoring and alerting, or devising a plan with an option for quick rollback if issues arise.
By disagreeing constructively and committing strategically, you position yourself as a problem-solver rather than a roadblock. This protects your career and helps you build influence and trust.
Step 3: Map Your Architecture
At one time you could trace your entire infrastructure by following network cables from physical servers to network switches and firewalls in datacenter racks that you own or lease. Those days are long gone. Today's architectures are virtual, highly distributed, and dynamic. But, there are tools to help you navigate:
OWASP Attack Surface Detector (ASD) - ASD is a Burp Suite plugin. It uses static analysis (source code required) to find hidden endpoints and parameters. You can read more about it here.
OWASP Amass - Amass is a framework that helps you discover network attack surfaces and external assets using open source intelligence gathering and reconnaissance. You can read more about it here.
ThreatMapper - Threatmapper is an open source cloud native application protection platform. It also produces a threat graph, which can be helpful for mapping your attack surface. You can learn more about it here.
By leveraging these tools, you can begin to piece together a comprehensive map of your architecture, identifying potential weak points and unnecessary attack surface alone the way.
Finally
Every year, we hear about breaches caused by forgotten, unknown, unmonitored, or simply unnecessary assets. These are the equivalent of leaving the back door unlocked—and they are entirely preventable through attack surface reduction.
Please let me know what you think.
Here are a few resources to help you dive deeper:
Diving Deeper
Subscribe to the Newsletter
Join other product security champions getting deep dives delivered to their inbox for free every Tuesday.
Follow us:
Quick Links
Supports Links
Quick Links
