Phishing emails and the use of unencrypted Hypertext Transfer Protocol (HTTP) protocol remain persistent channels through which malicious actors can exploit vulnerabilities in an organization’s cybersecurity posture. Attackers may spoof a domain to send a phishing email that looks like a legitimate email. At the same time, users transmitting data via unencrypted HTTP protocol, which does not protect data from interception or alteration, are vulnerable to eavesdropping, tracking, and the modification of the data itself.

 

Breaking Down the Attack: How It Works

Email  An attacker spoofs the domain of a reputable organization, and sends an email that looks to be a legitimate message.

Web  Data sent over HTTP is susceptible to interception, manipulation, and impersonation. This data can include browser identity, website content, search terms, and other user-submitted information.

Why It’s Effective…

Email  Other companies might receive spoofed emails, perceive them to be from an genuine source, and act on them. Internal employees may assume spoofed emails are legitimate and act upon them. If an attacker is successfully spoofing a domain in order to send malicious emails from it, this can significantly harm the affected organization’s reputation.

Web  Unencrypted HTTP connections create a privacy vulnerability and expose potentially sensitive information about the users of unencrypted websites and services.

Actions to Mitigate Phishing Email Attacks

  • When enabled by a receiving mail server, STARTTLS signals to a sending mail server that the capability to encrypt an email in transit is present. While it does not force the use of encryption, enabling STARTTLS makes passive man-in-the-middle attacks more difficult.
  • SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) allow a sending domain to effectively “watermark” their emails, making unauthorized emails (e.g., spam, phishing email) easy to detect. When an email is received that does not pass an organization’s posted SPF/DKIM rules, DMARC (Domain-based Message Authentication, Reporting & Conformance) tells a recipient what the domain owner would like done with the message.
  • Setting a DMARC policy of “reject” provides the strongest protection against spoofed email, ensuring that unauthenticated messages are rejected at the mail server, even before delivery. Additionally, DMARC reports provide a mechanism for the company to be made aware of the source of an apparent forgery, information that they would not normally receive otherwise. Multiple recipients can be defined for the receipt of DMARC reports.

Actions to Enhance Web Security

  • HTTP connections can be easily monitored, modified, and impersonated; Hypertext Transfer Protocol Secure (HTTPS) remedies each vulnerability. HTTP Strict Transport Security (HSTS) ensures that browsers always use an https:// connection, and removes the ability for users to click through certificate-related warnings.
  • Organizations should consider progress on HTTPS and HSTS deployment, such as removing support for known-weak cryptographic protocols and ciphers.

Where to Get Started

Recommendations for enhancing email security

  • Configure all internet-facing mail servers to offer STARTTLS, and all second-level organization domains to have valid SPF/DMARC records, with at minimum a DMARC policy of “p=none” and at least one address defined as a recipient of aggregate and/or failure reports.
  • Ensure that Secure Sockets Layer (SSL) v2 and SSLv3 are disabled on mail servers, and 3DES and RC4 ciphers are disabled on mail servers.
  • Ensure that organizations add the technology leadership team as a recipient of DMARC aggregate reports.
  • Set a DMARC policy of “reject” for all second-level domains and mail-sending hosts.

Recommendations for enhancing web security

  • Ensure that all publicly accessible websites and web services provide service through a secure connection (HTTPS-only, with HSTS), SSLv2 and SSLv3 are disabled on web servers, and 3DES and RC4 ciphers are disabled on web servers.
  • Identify and provide a list of second-level domains that can be HSTS preloaded, for which HTTPS will be enforced for all subdomains to the technology systems group charged with managing these recommendations.
  • Consider drafting a report to the technology steering committee on the status of implementation.
  • Collect input from vendors and other relevant parties to help avoid system constraints.

Final Observations

  • Due to a general misunderstanding about how DMARC works, and the potential fear of “missing” emails, the technology leadership team should create informational documents to share with non-technical staff.
  • Many companies do not understand the need to protect non-sending email domains with DMARC. DMARC adoption helps organizations better understand email use and categorize mail sending domains.
  • Businesses need higher-level strategic governance to guide their actions concerning these standards. Future changes in an environment could result in increased vulnerability.
  • Exercise caution when entering records on DNS as it is sensitive to errors.
  • While the goal is to reach 100% adoption of mitigation best practices, an organization’s environment can fluctuate, causing unevenness in maturity. Adoption progress tends to ‘mature’ at the 90-95% mark, on average.
  • Many companies, particularly smaller ones, may lack DMARC expertise and require support in order to implement DMARC. Additionally, reading and understanding DMARC reports is extremely difficult without the proper tools and insight.