How to Overcome Security Concerns at the Edge

Security is a top concern for every company today, so it should come as no surprise that it’s also one of the top five must-haves in an Edge as a Service (EaaS) solution. Edge computing topologies introduce both opportunities and threats when it comes to protecting applications from potential security breaches. On the one hand, processing data closer to end devices allows for earlier threat detection and mitigation, before attack agents are able to penetrate mission-critical operations. However, distributing workloads across a heterogeneous network of providers and infrastructure can also significantly expand the attack surface.

EaaS solutions must be designed with protection in mind, providing excellent defense against a diverse set of threats across the infrastructure, network, transport, and application layers. Let’s take a closer look at some of the top security concerns related to each layer with some insights from our recent white paper on Solving the Edge Puzzle.


The domain name system (DNS) is often referred to as the phonebook of the Internet since it translates domain names to IP addresses, allowing browsers to load Internet resources. DNS provides the hierarchical naming model, which lets clients “resolve” or “lookup” resource records linked to names. DNS therefore represents one of the most critical components of networking infrastructure.

Other widely used Internet protocols have started to incorporate end-to-end encryption and authentication. However, many widely deployed DNS services remain unauthenticated and unencrypted, leaving DNS requests and responses vulnerable to threats from on-path network attackers. Hence, when building out DNS services, it’s critical to maintain a security-first approach.


Transport Layer Security (TLS) is an encryption protocol that protects communications on the Internet. You can feel reassured that your browser is connected via TLS if your URL starts with HTTPS and there is an indicator with a padlock letting you know that the connection is secure. TLS is also used in other applications, such as email and Usenet. It’s important to regularly upgrade to the latest protocol for TLS and its predecessor, the SSL protocol.

When working with TLS and/or SSL, you have to either work with your own certificates using a managed service such as DigiCert or use an open source version with a service like Let’s Encrypt or Certbot. The managed certificate authorities such as DigiCert will provide automated tooling to provision certificates. With the open source versions, you will find that you must build the services to manage auto-renewal components and the provisioning of new certificates.

An added complexity is the question of how to deploy these protocols? In relation to distributed systems, you will have certificates that need to be running in multiple places. They might be running across multiple providers; for example, you might be using one specific ingress controller in one location and a different ingress controller in another. How do you ensure that your certificates are being deployed where needed to handle the TLS handshakes? And as the number of domains that you manage increases, so too do the complexities.

This ties directly back to DNS since you need to ensure that you’re routing traffic to the correct endpoints containing the workloads where your TLS certificates are deployed. Further, you will have to consider the state of your systems at any point in time and how you route traffic, since you never want to service users incorrectly.

Ultimately, servicing your user correctly is the end goal, meaning that when implementing TLS at the edge yourself, you must take into account all of these different components.

DDoS: Protecting Layers 3, 4, and 7

When protecting against Distributed Denial of Service (DDoS) attacks across distributed systems, the first question to ask should be, where are my systems most vulnerable to attack? The primary layers of focus on protecting against DDoS attacks include Layers 3, 4, and 7 in the OSI model.

osi model Web application firewall (WAF) providers will provide DDoS protection for you at the application layer (i.e., Layer 7). However, in an edge computing paradigm that’s made up of heterogeneous networks of providers and infrastructure, there are more questions that need asking. The most important being: How do all the different providers I’m using handle network and transport-layer DDoS attacks (i.e., Layers 3 and 4)?

All major cloud providers typically have built-in DDoS protection, but when you begin to expand across a multi-cloud environment, and further out to the edge, you need to ensure that your applications are protected across the entire network. This includes knowing how each underlying provider handles DDoS protection, along with implementing safeguards for any areas in your networks that may be underprotected. This takes us back to DNS and the question of how to handle traffic routing when one (or more) of your endpoints becomes compromised.

Web Application Firewalls (WAFs) & Bot Management Tooling

DevOps teams are increasingly choosing to deploy WAFs and bot mitigation tools across a distributed architecture, with the goal of detecting and mitigating threats faster. These solutions typically act as reverse proxies, monitoring, filtering, and blocking HTTP traffic to and from a web service based on a set of defined rules or logic.

While many best-in-class WAF and bot management technologies have emerged – providers such as Wallarm, Snapt (WAF), ThreatX, Signal Sciences, Radware Bot Manager, and PerimeterX – the most common selection and deployment method for these solutions is via a CDN’s proprietary service, which are often limited in functionality and flexibility. In fact, we often speak with developers who are frustrated with the “black box,” built-in solutions of legacy CDNs, and demand more choice and flexibility.

Edge as a Service: Solving for Security

As covered in our whitepaper, an Edge as a Service (EaaS) provider can help overcome security concerns along with many of the other complexities involved in application deployment and management at the edge. Section’s EaaS platform is built on top-tier hosting providers, extending all of the network layer protection and capacity provided by industry heavyweights like Amazon, Google, Microsoft, Lumen, etc. In addition to the core security features built into the platform, Section partners with industry-leading security solutions that can be easily deployed alongside your distributed applications, including advanced WAF and bot management technologies.

Similar Articles