4 Key Steps to Securing Your Company’s Internet-Facing Assets

Think about your company’s digital footprint on the internet today: every server, every service, every development, QA or production environment attached to the internet. Every open port. Every upcoming renewal you didn’t quite get around to that’s still up. Every service you think you turned off because the AWS console showed a big red “stopped,” but the query on the website it was hosting is still running right there. Every half-forgotten VM that you think is being decommissioned eventually. Every entire corner of the attack surface you weren’t even aware you owned.

Securing Internet-Facing Assets

Step 1: Build A Complete Asset Inventory

You cannot protect what you are not aware of. Well, this is easier said than done. Simply put, it is a tedious task to document every device, API, cloud bucket, and subdomain potentially accessible on the internet pertaining to your organization. Outdated marketing content, forgotten test servers, or cloud storage activated by a developer two years prior and stayed unused ever since are just a few to mention.

The same thing applies internally as shadow IT – the compliance assessment’s most frequent discovery. You can’t argue the audit that IT did not create it. If it exists on the internet and connects to your infrastructure, you are responsible. Start using automated discovery solutions that scan your external infrastructure and cross-check your cloud billing and DNS details. The difference between what you believe you have and what you actually have is the most probable risk.

The cloud and its constituents require you to pay particular attention to this process. A wrong configuration for storage or an unprotected management console is not traceable through conventional network scans like servers but highly accessible for anyone using a browser.

Step 2: Run Scans On A Schedule That Matches Your Obligations

Once you have a sense of the assets you’re trying to protect, you need to assess what could go wrong. That’s where vulnerability scanning and penetration testing come in. These are foundational parts of a solid security program, mapping directly to requirements in several compliance frameworks.

First, vulnerability scanning: this is the basic hygiene for your external attack surface. Do you know exactly which servers and services are reachable from the internet? Congratulations, you’re already ahead of many breaches. Do you know which of those are missing patches or running known-vulnerable software? Bingo, you’re ahead even more.

An external attacker doesn’t care if the target system failed to install the patch released three weeks after the exploit was published, or whether the admin misconfigured the SSH server to allow password auth. They just care that, for either reason, they can walk through your front doors and take what they want. For companies handling cardholder data, PCI DSS spells this out directly – Requirement 11.2.2 requires quarterly external vulnerability scans performed by a qualified provider. Organizations need to engage a firm to run an asv scan on that quarterly cadence, since only an Approved Scanning Vendor’s results satisfy this requirement during an assessment.

Internal scanning is also hygiene, but for your internal network. Containing breaches is important, and the faster you can boot an intruder after they’ve compromised one box the better. Full stop.

Step 3: Triage Findings and Prove The Fix Worked

A scan report full of unranked vulnerabilities is close to useless. Some of those findings are theoretical. Others are actively being exploited in the wild against systems just like yours. Risk-based prioritization means ranking issues by real exploitability and business impact, not just by CVSS score.

Set a remediation SLA – critical findings patched within days, lower-severity ones within a set window – and hold to it. Patch management is the obvious lever here, but firewall rule changes, WAF configuration updates, and certificate renewals often close the same gaps. Then re-scan. This step gets skipped more than any other, and it’s the one auditors ask about directly: can you show that the fix actually closed the exposure, or are you just assuming it did?

Step 4: Monitor Continuously and Document Everything

Regular scans are important to identify vulnerabilities but they are not enough because new ports open, firewall configurations change, and certificates expire. Monitoring your logs from firewalls, cloud environments, and other edge services can help you identify and respond to those things that pop up between each assessment. Make sure that the things these logs would reveal are being measured and reported according to specific benchmarks, and remember to save the reports and alerts in a rock-solid system for years on end.

CIS Controls is a good place to begin because it establishes a baseline of what should be measured in relation to your information security posture and helps prioritize those activities according to the concept of how likely and severe the resulting outcome would be if the control failed.

Here’s the part that trips up otherwise solid security teams: if you don’t have the logs and reports to show that you measured what you wanted to measure, then you don’t have it. It’s not enough to know you hit specific benchmarks in terms of electrical voltage coming out of your rack power strips; you have to be able to print the graphs where that power was monitored. It’s the same kind of equation. If the evidence wasn’t stored, it doesn’t exist. Scan reports, remediation tickets, re-scan confirmations, monitoring logs – these are what an auditor actually pulls during a review. Treat documentation as a deliverable you produce at every step, not something you reconstruct afterward under deadline pressure.