The normal network architecture for reporting voting results in our upcoming election is straightforward: A regional election management system is operated by local officials, and tabulated results are sent across an encrypted link to an election results reporting server. When working properly, results are reported around the country like this:
Distributed denial of service (DDOS) risk exists for both the regional election management system (egress) and the election results reporting server (ingress). Since the gain to the attacker is greater for the aggregated ingress, we will explain the threat and mitigation based on attacks to the reporting server. But attackers can choose.
The most common DDOS attack on election reporting would involve a botnet-originated flood of junk packets designed to overwhelm the inbound capacity of the election results reporting server. The attack can be accomplished via bots inserted onto infected PCs or servers. Experts refer this as a Layer 3 DDOS attack. Here’s how it looks:
The typical mitigation involves a service provider like AT&T, Verizon, or Akamai detecting the increased volume and redirecting traffic (using BGP) from the reporting server to a so-called DDOS scrubber. The scrubber sifts through the traffic for evidence of DDOS and then filters based on source IP, packet size, or other metadata. Here’s how this looks:
If the scrubber firewalls are working properly, then they drop the bad traffic and tunnel the good traffic to the election results reporting server. Presumably, this would allow election results to flow properly. The tunneling is required to prevent good traffic from bouncing back to the scrubber (think about it – and you’ll see what I mean). Here’s the view:
It’s important for readers to understand how this works for two reasons: First, you should understand that it is perfectly normal to divert reporting results to alternate servers. These are neither secret nor unknown. And second, you should understand that while this process does include automation, it can introduce delays – usually minutes, but it can be longer.
Now – it would be great if every election results reporting server in the country was properly covered with such protection – and that the security teams supporting such complexes would have practiced to ensure readiness. But I would bet you a dinner that many are not. Which leads me to three recommended actions for anyone engaged in this line of work:
Readiness Action 1: Make sure you contact your ISP to ensure that you have inbound DDOS protection for volumetric attacks from botnets. It’s not an expensive service, but it does require planning and testing.
Readiness Action 2: Make sure an application expert reviews your reporting server software to disable unnecessary services. These can be exploited to initiate outbound DDOS-like attacks to overwhelm the server. This is called a Layer 7 DDOS attack.
Readiness Action 3: Make sure to take inventory of your DNS provider and ask if they are protected to maintain your domain in the face of DDOS attacks levied against them. If you don’t know who your DNS provider is – well, then God help us all.
If you have any sort of responsibility to administer election-related network, server, or application infrastructure, then I hope you will take these three readiness actions today. And for the rest of you and me – let’s watch for shenanigans from politicians who might call this diversion process fake or phony. It is both recommended and normal.
Let’s hope this isn’t a problem – but without a national Cyber Czar, the best we can do is hope that no malicious attacker does this.
