E-voting and DDoS concerns: The devil’s in the details

It’s a typical Wednesday. I’m sitting in the lounge at the Imperva office going through emails when I stumble onto a whitepaper titled Trust Implications of DDoS Protection in Online Elections. “That’s an interesting topic,” I think, and dive in. Coincidentally, this whitepaper turns out to be about our own DDoS protection service, which makes it even more interesting.

Reading the document, I quickly realize that I don’t agree with several assumptions and interpretations outlined in the paper. I would feel better if the researchers had contacted us to fact-check before publishing, but hey – the world’s not perfect. Although their whitepaper is focused on a specific case, I’ll generalize so as to tie it into our product suite.

Implementing privacy when doing global security analytics is challenging

First things first, our work is challenging, we protect important services. E-voting systems are just one example, but we also protect other critical government services; e-commerce applications, banks, and many other businesses and organizations. Every day our products are the shield between the organizations’ applications and attackers. We focus on several fronts – application security, DDoS mitigation, and database security.

When you provide a service that offers protection, there’s a certain amount of trust between you and your customers. For Imperva, this trust, especially when it comes to privacy issues, is hard earned and well deserved. For me personally, I wouldn’t consider working for a company that doesn’t prioritize its customers’ private data. That’s why I’m proud of the effort Imperva puts into making our solutions privacy-friendly, even though some privacy features make our work considerably more challenging.

Examples of some of these challenges are:

• Personally identifiable information (PII) and other sensitive information in logs are only analyzed within the singular Point of Presence (PoP) device and are then masked at that time before any subsequent log use. After that, the PII is not saved anywhere, including in logs, events, etc. PII, such as voter names, is not saved to disk nor is it sent over a LAN to another machine on the same PoP (point of presence), or outside of the PoP. To make this perfectly clear: if the voter name is “John Smith”, this name never gets written to a file, and in the log, it will become XXXXXXXXXXXXXXX.
• Imperva has hard-set rules and procedures about where information is stored (such as attack traffic), who can access this information, how they can use this data, etc. These rules, including those governing PII processing and masking, are not just audited internally, but are also subject to external auditing as part of our certifications (SOC 2, PCI, and others).

We do all this and more because we care deeply about our customers’ privacy. We do not believe that those concerned about their privacy are criminals, so we do not block or “auto-CAPTCHA” TOR network traffic.

Starting with the bottom line…

The best alternative to a DDoS mitigation solution is far worse than what’s written in the whitepaper. You either open yourself (as a voting service) to manipulations, or you go back in time and prevent online voting. Both are bad. Here’s why.

1. A DDoS attack on a voting system can hugely impact election results when individuals are not able to cast their vote in a timely fashion, if at all. And you can’t effectively protect against a DDoS attack without a cloud solution to absorb the attack.

2. In my opinion, online voting should be the norm. It allows for “next-gen democracy.” Many people would otherwise not vote. To be clear: I say that in my own opinion, despite the latest news about possible attempts to influence elections by foreign governments. We can’t let such risks hold us back, we need to protect against them but still move forward as the benefit is huge.

Our solution not only protects against DDoS attacks, but it also protects against application security attacks, such as attempts to breach the voting service by attacks such as Remote Code Execution, SQL Injection, etc. So yes, overall, what we’re doing is a good thing. But I do want to also comment on the specific claims in the whitepaper.

Getting back to the whitepaper…

The whitepaper states that “An internet-wide scan we conducted found valid TLS certificates for the election website being served by servers around the world.” This is true. This is also how web application protection on any content delivery network (CDN) works. The solution analyzes the traffic against attacks in the various Imperva PoPs around the world, so that when (because it’s not an if) attacks are detected, we can stop them as far away from the customer as possible. This is crucial for successful mitigations so as not to create a bottleneck close to the victim’s web infrastructure.

The claim that “Taken together we argue that this opens the possibility of a foreign nation being able to obtain the private key necessary to man-in-the-middle.” We take the security of our PoPs seriously, and there is no access to the boxes by local authorities. As to “It also risks compromising the election as a result of error or malfeasance by server administrators all over the world” – there are no “server administrators all over the world.” The proxies are deployed and updated by one team, our trusted Imperva DevOps applications and engineers, no third-party touches the content of our network.

In addition to that, 99% of the incoming encrypted traffic that passes through our CDN uses Perfect Forward Secrecy (PFC) ciphers. That means that even if SSL keys are somehow compromised, they can’t be used to decrypt past sessions.

As for the misconfiguration of allowing traffic from outside of the Incapsula network to the origin server if the attackers know the IP address of the server, I’m glad this was brought up. This is an important part of proper onboarding to our services (blocking all traffic not coming from Incapsula ranges).

Another attack scenario, according to the paper, would be if a malicious attacker injects malicious javascript as part of the javascript injections done by Incapsula. While this is true, it can also be said about any third-party JavaScript being loaded by web applications on the customer website, including a voting website (such as advertisements, analytics, monitoring and framework libraries). That’s why we take precautions to make sure that it doesn’t occur. Our environments are protected and audited, and any configuration change needs to be approved by multiple people in a process that is thoroughly tracked. Consequently, Imperva would know about a JS injection, even if the JS file remained in the same size.

Overall, I think that the practical conclusion of the whitepaper is that when doing DDoS mitigation (or any other security mitigation), certain issues need to be considered. Imperva as a leading DDoS-mitigation solution provider constantly ensures we deliver on our promises to not only keep our customers’ data and applications safe, but also to keep their data private and confidential. For us, it goes without saying. It’s part of what we do.