Securing 200+ Web Assets When You Don't Even Know What You Have

The Problem: You Can't Secure What You Don't Know Exists

I was tasked with securing the web assets of a multinational financial group with over 50 business units spread across multiple countries. The problem: nobody knew what those assets were.

At the start, only a fraction of our web assets had any form of security coverage. The rest existed outside any meaningful control.

There was no asset inventory. What we had was a short list of websites that had previously gone through some vulnerability assessments. That was it. No central register. No ownership records. Domains were purchased by individual business units whenever they needed one. DNS was managed however each team saw fit. Years of organic growth, shadow IT, and staff turnover had created a sprawling, ungoverned web estate. Some web properties had been spun up for development and never taken down. Others had changed hands so many times that nobody could tell you who owned them.

While I was working through this problem, one of our certificates expired on a static site belonging to a major business unit. The site showed a "Not Secure" warning for several hours before we caught it and renewed the cert. It was a static site, so the blast radius was limited, but the reputational risk for a financial brand was real. This wasn’t a failure of the project. It was a symptom of the underlying problem. We had no visibility, no monitoring, and no centralized cert management. That incident reinforced why this work was urgent.

This is how I went from having nothing to having full visibility and control over the entire web estate.

Phase 1: Asset Discovery

I happened to be running PoC evaluations for two threat intelligence platforms at the time, SOCRadar and Mandiant. I realized I could use their external attack surface management capabilities to find web assets that might belong to us.

I set up searches using company keywords, brand names, subsidiary names, and domain patterns. The platforms came back with over 430 results. That sounds great until you realize how TI-driven discovery actually works. It casts a very wide net. A lot of those 430 results were external websites that just happened to mention one of our keywords somewhere on their page.

The first round of cleanup was easy. I went through the list and removed about 100 sites that clearly had nothing to do with us. The rest took more time. I worked through them gradually and landed on roughly 200 web applications that appeared to be ours.

Without this process, a significant portion of the organization’s internet-facing assets would have remained unmonitored, unpatched, and effectively invisible to security.

Why Threat Intelligence Was the Right Starting Point?

The obvious question is why not just use internal tools for asset discovery. The answer is simple: we had nothing to discover from. Our only internal reference was a partial list of sites that had been through VA scans at some point. That list was incomplete by definition because it only covered assets we already knew about.

The real challenge with decentralized asset ownership is that the assets you need to worry about most are the ones nobody remembers exist. No internal CMDB, no spreadsheet, no ticketing system is going to surface a domain that was purchased three years ago by a team that has since been restructured. You need something that can look at the problem from the outside in.

These platforms do something no internal tool can: they scan the entire internet and surface assets associated with your organization based on keywords, brand names, and domain patterns. They see what an attacker would see, which is exactly the perspective you need when you don't know what's exposed.

Phase 2: Verification & Ownership

This was the hardest part of the entire project.

I had to sit down with every relevant business unit head and go through the list to verify each asset. Who owns this? Is this still active? What does it do? In a lot of cases, the BU heads themselves had no idea these sites existed. Shadow IT, people changing roles, teams restructuring, things just get forgotten over time.

I also got on calls with developers and tech leads to go through DNS records one by one. A lot of records had been created for dev or staging environments and never removed after the project wrapped up. These forgotten records were a real risk and I wanted to draw the line there first.

The one thing that made this whole phase possible was the security culture at the organization. Everyone was willing to help. Nobody pushed back or treated it as a nuisance. Without that, the project would have stalled here.

Phase 3: Risk-Based Classification & Protection

Not every web asset carries the same risk, so I needed a way to identify the crown jewels.

I used three criteria.

1. First, data sensitivity. If the site handles PII or financial data, it's a crown jewel.

2. Second, reputational impact. A financial company's homepage getting hacked is a completely different situation than a static website for a hotel. No customer is going to trust an online banking platform that's been compromised. And then there are the lawsuits and regulatory fallout on top of that.

3. Third, compliance obligations. Some sites fell under ISO 27001 or PCI-DSS, which meant scheduled vulnerability assessments were mandatory, not optional.

With assets classified, I started securing them with a WAF.

Two-tier WAF architecture

Crown jewels went behind Imperva WAF on the enterprise plan. These were the sites handling sensitive data, the ones with compliance requirements, and the ones where a breach would cause serious reputational damage.

Everything else went behind Cloudflare WAF on the Pro plan. For static sites and lower-risk properties, spending an Imperva enterprise license made no sense when Cloudflare Pro could provide adequate protection at a much lower cost.

This was a cost-aware decision, not just a security one. The goal was right-sizing protection to risk, not throwing the most expensive tool at everything.

Phase 4: Building Governance That Sticks

Cleaning up the mess once is fine. Making sure it doesn't happen again is what actually matters.

My first move was to push for a group security policy mandating that all domains are managed by InfoSec. This needed approval from the CISO and the board of directors. I had to explain why centralized domain management was necessary and what the risks were if we kept the status quo.

The group policy removed the option to bypass the process. Domain ownership was no longer a decentralized decision.

No individual BU head can override a group policy. But honestly, nobody wanted to push back anyway. The way I structured it, InfoSec took on full responsibility for domain security. If a domain expired or got exposed, that was on us. No BU head was going to volunteer to take on that liability just so they could change a DNS record themselves.

The leverage: When your process has clearly defined SLAs and OLAs with zero violations, nobody has a reason to circumvent it. Reliability is the best political tool in enterprise security.

I also set up a formal approval workflow for any domain activity. Buying a new domain, changing DNS, transferring ownership, all of it goes through the same chain: Requester, Department Head, BU Head, InfoSec.

What Else Changed?

By the end of the project, the organization had moved from fragmented visibility to centralized control. The impact was measurable.

Measurable Outcomes

Lessons Learned

Most security programs fail because they start with controls instead of visibility.

The instinct is to deploy tools right away. But without a complete and verified asset inventory, you are only covering a fraction of your actual exposure. Discovery comes first.

The assets that hurt you are the ones you don't know about.

Over 430 potential assets were out there and InfoSec had no idea. Without external, TI-driven discovery, most of them would have stayed invisible indefinitely.

Tools don't matter if people won't work with you.

The best WAF in the world is useless if business units refuse to cooperate. The security culture at this organization made the entire project possible. Invest in relationships before you invest in technology.

One-time cleanups solve nothing without governance.

The approval workflow and the group policy mandate were probably the most impactful things I delivered. They are what turned a cleanup project into a lasting security program.

The real win here wasn't technical. It was operational control. By absorbing domain management responsibility into InfoSec, we created a situation where following the process was easier than going around it. Nobody had a reason to circumvent it and nobody wanted to.

This effectively became an external-first asset discovery and governance model.

Replicability

This approach is not unique to my situation. Any organization dealing with decentralized asset ownership, accumulated shadow IT, and missing inventories can follow the same pattern: use external discovery to find what internal tools can't see, validate everything through people, classify based on risk, right-size your protections, and build governance that makes compliance easier than circumvention.

The combination of external discovery, human validation, and enforced governance is what makes this repeatable. The specific tools matter less than the framework.