Internal Endpoints Must Have The Same Security Capabilities As External Endpoints

In a previous post, we made a point of “Non-Prod Environments Must Have The Same Security Protections As Production”. In this post, we’re going to go one step further and say that your internal and external endpoints, generally, should have the same security capabilities baked into their security model.

Historically, most organization, most individuals assume that “internal” equals “trusted”. Don’t do this. This may vary well be one of the largest security architecture blunders you can make. Modern security models (like Zero Trust Architecture) assume every endpoint should authenticate and authorize every request regardless of network location.

External Endpoints are exposed to the internet along with bots, scanners, attackers, and bored teenagers. Even if you have firewall between the endpoint and the public internet, assume that there is still potential for vulnerabilities. Are you prepared to trust, unconditionally, all of your business partners, suppliers, vendors, customers, etc that call this endpoint? And, that their networks will never be compromised?

Typical examples of External Endpoints include:

• Corporate websites
• Public APIs
• SaaS APIs
• Login portals
• Customer web apps

Internal Endpoints are less exposed but still dangerous because attackers often move laterally after initial compromise.Internal (Private Network) Application Endpoints

Internal endpoints are usually:

• Microservices
• Internal APIs
• Admin dashboards
• Service-to-service communication

It’s impossible to provide a general purpose security architecture that will fit every situation. I originally used the following sample security architecture in the “SOFTWARE SUPPLY CHAIN SECURITY: CI/CD/CT PIPELINES AND SECURITY TOOLS — PART 2” post:

It’s not my intention to present this as an all-purpose security architecture, but merely as a reference point for a typical web application. Your mileage will vary. What is important is the security capabilities that are depicted, including, but not limited to:

• Authentication (SSO w/ Multi-Factor Authentication)
• Authorization
• Integrity
• Confidentiality (data encryption at rest and inflight)
• Non-repudiation
• TLS (possibly MASSL/MATSL) at every network hop (an extension of Confidentiality)
• WAF (including bot detection)
• API Gateway (API Authn, API Coarse Grained Authorization, Rate Limiting, Request Validation based on an API Spec, etc)
• DDoS Prevention Service
• Network Segmentation (macro / micro / VLANs / traditional firewalls )
• Logging (Audit / SIEM / Application / Infrastructure)
• IDS / IPS

Now, do we really need WAF and DDoS Prevention Service for internal endpoints? It depends on the situation. If the application endpoint is called from a vendor DMZ, any other external entity connected through private networking, or maybe another business unit that you have no control over, then, yes, maybe, you do want these capabilities in place. One would also want the other capabilities of the API Gateway mentioned in this scenario.

If you are using cloud-based services for your WAF or DDoS Prevention Service, it is most likely going to be difficult to deploy that on your internal network unless it is hosted on a public cloud provider. Or, one of the options that extends cloud services to an onprem data center (AWS, GCP, Azure).

There are various solutions that provide WAF / DDoS Prevention Services onprem. F5 BigIP and similar appliances offer these capabilities onprem (WAF, DDoS Prevention), but generally aren’t as scalable as the public-cloud hosted options.

To the greatest extent possible, the internal endpoints should have the same security capabilities deployed as the external endpoints.