We wanted to know: what’s the state of email and web security for the 2020 presidential candidates?
With the DNC email hack in 2016, cybersecurity played a major role in the outcome of our last presidential election. Our team of researchers was curious: what’s changed since 2016? What’s the state of email and website security for the 2020 presidential candidates? In short, have stronger security protections been put in place since 2016 or has nothing changed?
To try to answer these questions, we looked at publicly-available data – the types of data you interact with on a regular basis by visiting websites or receiving email messages. We limited our scope to non-intrusive tests and analyzed three aspects of email security and two aspects of website security for the 2020 presidential candidates’ campaigns, using the New York Times’ list of current candidates.
We recognize that the five areas we examined don’t represent a complete assessment of the cybersecurity posture of the candidates’ campaigns, nor was it an exhaustive assessment of publicly available data about the campaigns’ websites and email. However, we do think it sheds light on whether the candidates are taking full advantage of a set of freely-available security protocols that are designed to secure their websites and email platforms.
Here’s how they stacked up.
Why is email security so important?
Skilled attackers typically follow similar paths: first, they gain a foothold into an organization by compromising a soft target such as a staff computer, tablet, or phone that is connected to the organization’s internal network. Once in, attackers will attempt to pivot, moving from one system to another, actively looking for additional vulnerabilities while capturing high-value assets – passwords to other systems, bank account details, Social Security Numbers, credit card numbers, personnel files, insurance numbers, etc. If the attack is targeted at a specific organization such as a campaign, attackers might also be looking for strategic plans, operational reports, or any other information that can be used for malicious or strategic purposes.
Many intrusions today start out with email, specifically with a phishing attack, to gain that initial foothold into an organization. In these situations, an email is sent that impersonates (or “spoofs”) a legitimate sender such as the Google or Office 365 security team, the CEO of your company, or an important client. With phishing attacks, it’s not just about getting people to open a message, but tricking them into logging into a fake website, one that is run by the attackers and captures all data entered there, including usernames and passwords. This approach is likely how the DNC was hacked in 2016 – it appears that messages were sent that spoofed Google, asking users to reset their Google passwords.
Continue reading for our full assessment, or jump to the end for the FireOak scorecard.
Part 1: Email Security for the 2020 Presidential Candidates
Fortunately, there are mechanisms available to make it more difficult for attackers to spoof senders’ information. We examined three of these mechanisms – all of which are free to implement – to see which are in use among the campaigns. In all cases, we relied on publicly available data for our analysis.
Email Security Item #1: SPF
The first item we examined was the Sender Policy Framework (SPF) for email sent by the candidates’ campaigns. Through SPF, email system administrators create a record with a whitelist of which systems are permitted to send messages on behalf of their specified domains. For example, at FireOak we use Microsoft Office 365 to host our email, so our SPF record for the fireoakstrategies.com domain includes the addresses of various Microsoft servers that handle our email.
For the candidates, we looked to see which have SPF records for their official domains.
Finding: All of the candidates are using SPF and have SPF records. (Good!)
Next, we signed up for the mailing lists so we could receive email from all of the candidates. During the timeframe in January 2020 when we collected data, we received at least one message back from all of the candidates except from the Trump campaign. Once we received a message from a candidate, we compared the data in the email header with the data included in the associated SPF record.
Here’s an example of SPF validation as it appears in the headers of an email sent from fireoakstrategies.com:
Finding: All of the candidates from whom we received messages passed SPF validation. (Also good!)
Since SPF is a whitelist of allowed senders, it can also be used to find out which email services a particular organization is using. The figure below shows which services are in use on behalf of the candidates’ campaigns, based on their SPF records. While not directly a security issue, it was interesting to note that nearly all of the candidates are using Google for email. It is also possible to glean some information about what other service providers the candidates are utilizing. For instance, several candidates appear to be working with the marketing firm, Blue State Digital, and a few candidates are using Shopify to sell their merchandise.
Another interesting tidbit: one candidate has listed _phishspf.knowb4.com in his SPF record, a service which provides email security training. Considering the DNC hack started with a Google account reset message, it is good to see that at least one candidate is conducting phishing tests and training. (We don’t know either way if other candidates are conducting this type of training.)
Email Security Item #2: DKIM
Next up in our analysis was to look at DomainKeys Identify Mail (DKIM), a method of using public key cryptography to digitally sign messages.
With the DKIM protocol, email system administrators share a domain’s secret, private key with each server that has been authorized to send messages on behalf of their domain. For instance, we’ve shared our private key with Office 365 email servers so Office 365 can send messages from fireoakstrategies.com.
Here’s an example of a DKIM signature in the header of an email sent from fireoakstrategies.com:
Once you’ve shared a private key with a company who is sending messages on your behalf, all messages sent from that source will be cryptographically signed using the private key. A digital signature is included in the header of email messages. When the recipient’s email server receives a message, it then tries to validate the digital signature against the public key stored in the public Domain Name System (DNS).
Verifying signatures ensures not only that the message wasn’t forged – it came from where it says it came from – but it also ensures that a message wasn’t tampered with as it traveled across the internet from the sender’s server to the recipient’s server.
DKIM keys can be given arbitrary names, so it isn’t possible to determine whether a domain is using DKIM by looking at public DNS records. Instead, we reviewed the headers from messages we received from the candidates’ campaigns after signing up for their mailing lists.
Finding: All messages that we received were properly signed with a valid DKIM signature. (Hooray!)
Again, no data from Trump campaign since we did not receive an email during our data collection phase.
Email Security Item #3: DMARC
Domain Message Authentication, Reporting, and Conformance (DMARC) is another email protocol. Through DMARC, systems administrators create policies that define what an email server will do if an incoming message fails SPF and/or DKIM validation. If a DMARC policy is not in place, the receiving mail server determines how to handle messages that fail SPF and/or DKIM validation.
The DMARC protocol also allows for some reporting, which can be useful. As part of the policy set via DMARC, it is possible to request a report whenever another domain receives a message from your domain that fails SPF and/or DKIM validation. For instance, if a message is sent to Google from the fireoakstrategies.com domain that fails SPF or DKIM validation, our system administrator will receive an automated report from Google with this information. From a security perspective, these reports can be helpful in testing and monitoring that your organization’s SPF and DKIM records are properly setup and configured.
Properly configured email systems should (a) have a DMARC policy, (b) the policy should be set to reject all messages that fail validation, and (c) opt for reports.
For example, the effect of the DMARC policies we’ve set for the fireoakstrategies.com domain appear in email headers such as the one below. In this example, DMARC validation is indicated as “pass.”
While all of the candidates from whom we received messages were using validated SPF and had a valid DKIM signature, we started to see vast differences in security among candidates with respect to DMARC.
Finding: Candidates with domains that have a DMARC policy set to reject all messages that fail validation and are receiving failure notification reports: Biden, Bloomberg, Gabbard, Klobuchar, Steyer, and Warren. (FireOak Assessment: Excellent!)
An alternative to setting the DMARC policy to “reject” is to instruct the recipient’s email to place into quarantine all messages that fail SPF and/or DKIM validation. These messages would then get marked as spam or junk. Users can access these messages if they navigate to a spam/junk folder, but they’re harder to find. From a security perspective, quarantining isn’t ideal because it is still possible for spoofed messages to be received and acted upon, but it’s certainly a better approach than the next few options. On the plus side, both of these candidates’ campaigns have enabled reporting for SPF/DKIM validation failures.
Finding: Candidates with DMARC policy set to quarantine: Buttigieg and Yang (FireOak Assessment: Pretty good)
Setting a DMARC policy of “none” is an option that is generally reserved for testing and shouldn’t be used once a campaign is launched. A DMARC policy of none provides no additional control over whether failed messages are delivered – which means that spoofed messages might be making their way to recipients’ inboxes. On the plus side, these candidates’ campaigns have enabled reporting for SPF/DKIM validation failures, so potentially they should have some visibility into whether their legitimate messages are being delivered.
Finding: Candidates with a DMARC policy set to none: Delaney, Patrick, Sanders, and Trump (FireOak Assessment: Not good)
Finally, some campaigns don’t have a DMARC policy. The overall effect is the same as having a policy of “none” but without the reporting capabilities that are provided by DMARC.
Finding: Candidates without a DMARC policy: Bennet, Walsh, and Weld (FireOak Assessment: Not good)
Summary: Only 6 of the candidates are taking full advantage of the security protections offered by DMARC.
Part 2: Website Security for the 2020 Presidential Candidates
Assessing the security of a website can be a detailed and somewhat invasive process and shouldn’t be carried out without express permission from the site owners. For the purposes of this assessment, we’ve looked at two aspects of how the candidate websites handle security and encryption by analyzing the data sent to our computers during the process of visiting each site. While this type of assessment is very limited in scope, it can provide insights to how security was taken into consideration when the sites were developed.
Website Security Item #1: Transport Layer Security (TLS) Protocols
Over the past decade, the internet has made tremendous progress in moving from the Hypertext Transfer Protocol (HTTP) to HTTPS, where “S” stands for “Secure.” Data transmitted via HTTPS is encrypted using the Transport Layer Security protocol, often abbreviated as TLS. TLS replaced the older Secure Sockets Layer (SSL) protocol, but the use of the abbreviation “SSL” is still in common use.
Technology in this space evolves quickly. TLS 1.0 (released in 1999) is obsolete and should no longer be used. TLS 1.1 is still valid, but it is on its way out. TLS 1.2 is the modern, widely accepted standard. TLS 1.3 is much stronger, but it has been met with some resistance due to conflicts with some types of firewalls that are common in many corporate environments.
We examined the protocols in place on the presidential candidates’ websites to see who was using which versions of TLS.
Industry best practice is to disable the use of TLS 1.0 and to begin to phase out TLS 1.1. In fact, the rules that govern security requirements for websites which process credit card transactions (PCI) have disallowed the use of TLS 1.0 since 2018.
Finding: Only six of the candidates are following current best practices and have disabled TLS versions 1.0 and 1.1: – Biden, Bloomberg, Delaney, Steyer, Walsh, and Yang. (Good!) The rest of the candidates’ servers support the outdated TLS version 1.0 protocol. (Not good.)
Website Security Item #2: Cipher Suites
The specific details of how encryption takes place between a web server and a browser is determined through a negotiation that occurs when a browser first connects to a secure site. A browser sends a list of cipher suites – a standards-based set of encryption methods – that the browser supports to the remote server. The remote server chooses one from the list that the browser supports, and that’s the encryption method that both ends will subsequently use.
Details about the TLS version and cipher suites in use on a website are visible in the developer tab of most modern web browsers. The example below is from the FireOak website.
Some cipher suites are stronger than others. Some older suites have known weaknesses that could be exploited by an attacker in order to extract the plain-text content of the otherwise encrypted communication.
We examined candidates’ websites to see which cipher suites are supported.
Most of the websites are using modern cipher suites. However, a few of the candidates are using cipher suites that use a cryptographic method called Cipher Block Chaining (CBC). Some CBC-based cipher suites, when used in conjunction with the older TLS 1.0 protocol, contain a vulnerability that that could allow a sophisticated attacker to decrypt traffic.
FireOak’s Scorecard: Email and Website Site Security for the 2020 Presidential Candidates
To rank the state of email and website security for the 2020 presidential candidates, we assigned up to three points (admittedly arbitrarily) to each finding starting with the DMARC analysis. For the DMARC policy, we assigned one point for a DMARC record having a policy of “none,” two points for a policy of “quarantine,” and three points for a policy of “reject.” For the remaining categories, we assigned three points if no weaknesses were found. We didn’t assign points to the SPF and DKIM findings, as the findings were generally uniform across all the candidates.
Based on our scoring, there was a three-way tie for first: Biden, Bloomberg, and Steyer all tied with 9 points, with Yang close behind with 8.
Final Thoughts about Email and Website Security for the 2020 Presidential Candidates
Overall, we were surprised to see that incomplete email security implementations and older encryption protocols were common among many of the candidates’ systems. Considering how big of a role email security played in the last election, we were shocked to find that several of the candidates are still not following industry best practices to secure their email, particularly when it comes to preventing spoofing.
It is worth noting that all of the items we examined are standard features of most email and website hosting services. There’s no cost associated with any of these items, unlike many other security controls. In short, there’s no excuse for not having these protections in place.
FIREOAK STRATEGIES, LLC is a boutique consulting firm specializing in knowledge management, information security, and information/data management. We help organizations manage, secure, and share their information, data, and knowledge. FireOak is a certified Woman-Owned Small Business (WOSB) and Women’s Business Enterprise (WBE). FireOak was named the Knowledge Management Consulting Services Company of the Year in 2019 by CIOReview. FireOak Strategies was founded in 2010 and is based out of Durham, North Carolina.