Binding Operational Directive 18-01

October 16, 2017

Enhance Email and Web Security

This page contains a web-friendly version of the Department of Homeland Security’s Binding Operational Directive 18-01, “Enhance Email and Web Security”, and provides technical guidance and best practices to assist in its implementation.

For an overview of this directive’s requirements, review the checklist.

A binding operational directive is a compulsory direction to federal, executive branch, departments and agencies for purposes of safeguarding federal information and information systems.

The Department of Homeland Security (DHS) develops and oversees the implementation of binding operational directives pursuant to the Federal Information Security Modernization Act of 2014.

Federal agencies are required to comply with DHS-developed directives.

DHS binding operational directives do not apply to statutorily defined “National Security Systems” nor to certain systems operated by the Department of Defense or the Intelligence Community. Id. § 3553(d)-(e).

I. Background

Federal agency “cyber hygiene” greatly impacts user security. By implementing specific security standards that have been widely adopted in industry, federal agencies can ensure the integrity and confidentiality of internet-delivered data, minimize spam, and better protect users who might otherwise fall victim to a phishing email that appears to come from a government-owned system.

Based on current network scan data and a clear potential for harm, this directive requires actions related to two topics: email security and web security.

A. Email Security

STARTTLS

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.

Email Authentication

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 doesn’t pass an agency’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 an agency to be made aware of the source of an apparent forgery, information that they wouldn’t normally receive otherwise. Multiple recipients can be defined for the receipt of DMARC reports.

B. Web Security

Hypertext Transfer Protocol (HTTP) connections can be easily monitored, modified, and impersonated; 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.

In 2015, OMB M-15-13 required all existing Federal websites and web services to be accessible through a secure connection (HTTPS-only, with HSTS). In 2017, the .gov registry began automatically preloading new federal .gov domains as HSTS-only in modern browsers.

Federal agencies must make more progress on HTTPS and HSTS deployment, including by removing support for known-weak cryptographic protocols and ciphers. According to DHS’s Cyber Hygiene scanning data, seven of the ten most common vulnerabilities seen across federal agency networks at the issuance of this directive would be addressed through complying with the required actions in this directive related to web security.

II. Required Actions

All agencies are required to:

  1. Within 30 calendar days after issuance of this directive, develop and provide to DHS an “Agency Plan of Action for BOD 18-01” to:

    a. Enhance email security by:

    i. Within 90 days after issuance of this directive, configuring:

    • All internet-facing mail servers to offer STARTTLS, and
    • All second-level agency 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.

    ii. Within 120 days after issuance of this directive, ensuring:

    • Secure Sockets Layer (SSL)v2 and SSLv3 are disabled on mail servers, and
    • 3DES and RC4 ciphers are disabled on mail servers.

    iii. Within 15 days of the establishment of centralized National Cybersecurity & Communications Integration Center (NCCIC) reporting location, adding the NCCIC as a recipient of DMARC aggregate reports.

    iv. Within one year after issuance of this directive, setting a DMARC policy of “reject” for all second-level domains and mail-sending hosts.

    b. Enhance web security by:

    i. Within 120 days after issuance of this directive, ensuring:

    • All publicly accessible Federal 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.
    • Identifying and providing a list to DHS of agency second-level domains that can be HSTS preloaded, for which HTTPS will be enforced for all subdomains.
  2. Upon delivery of its Agency Plan of Action for BOD 18-01 within 30 days of this directive per required action 1, begin implementing that plan.

  3. At 60 calendar days after issuance of this directive, provide a report to DHS on the status of that implementation. Continue to report every 30 calendar days thereafter until implementation of the agency’s BOD 18-01 plan is complete.

III. DHS Actions

IV. Potential Budgetary Implications

DHS understands that compliance with this BOD could result in budgetary implications. Agency Chief Information Officers (CIOs) and procurement officers should coordinate with the agency Chief Financial Officer (CFO), as appropriate.


Introduction to Email Authentication

The Department of Homeland Security seeks to incentivize the thoughtful deployment of email authentication technologies and generally increase the security of messages to and from government agencies. Email that fraudulently uses a Federal domain should be easy to detect.

This section is a recital and elaboration of key points in two recent Federal documents:

  1. Special Publication 800-177, Trustworthy Email, which the National Institute of Standards and Technology issued in September 2016
  2. Businesses Can Help Stop Phishing and Protect their Brands Using Email Authentication, issued in March 2017 by the Federal Trade Commission’s Bureau of Consumer Protection based on a study performed by the Office of Technology Research and Investigation

What is email authentication?

“Email authentication” refers to a set of technologies that enable:

Email authentication can impede the delivery of phishing emails that attempt to play off an organization’s domain names. This protects:

There are three predominant forms of email authentication technology: SPF, DKIM, and DMARC. Conceptually, each operate similarly:

  1. When an email arrives at a recipient mail server, it queries the sending domain’s DNS to check for relevant email authentication records.
  2. If email authentication records are found, the server evaluates the email it received against the email authentication records and makes a determination: deliver it, deliver it but mark it as questionable, or discard it altogether.

See SP 800-177, section 4 for a detailed technical description.

What are the standards that enable email authentication?

SPF & DKIM

In effect, both these techniques allow a sending domain to “watermark” emails from their domain, making spoofed emails easier to detect.

However, there is no inherent or widely-implemented mechanism in either standard to signal what a recipient should do with messages that fail SPF/DKIM validation. DMARC serves this role.

DMARC

Domain-based Message Authentication, Reporting and Conformance, or DMARC, serves three primary functions:

Alignment and Conformance

Different than the RFC5321.From address that is sent in the initial SMTP transaction, the RFC5322.From address (also known as the message-From address) is typically the email address that is represented as the sender in email clients. DMARC requires “alignment” between the domain in this very visible address and the domains that are authenticated in SPF and DKIM. This alignment can be “strict” (an exact match) or “relaxed” (must be a subdomain of the parent domain). Alignment is fully tunable in DMARC, with different options for SPF and DKIM alignment. DMARC’s default for alignment is “relaxed”.

In order to satisfy DMARC filtering, at least one of either SPF or DKIM must “pass” their authentication checks and be in alignment with the domain in the message-From address.

If not, DMARC allows a sender to set one of three separate policy states for email disposition:

  1. block delivery of unauthenticated messages (noted in the DMARC record as p=reject),
  2. place unauthenticated messages in the recipient’s junk email folder (p=quarantine), or
  3. specify no guidance on how to treat unauthenticated messages (p=none). This setting should be viewed as a temporary policy setting before getting to p=quarantine and p=reject, and is only meaningful when coupled with reporting.

In other words, by using DMARC, a sending domain can instruct receiving email servers to block delivery of all unauthenticated messages – such as phishing messages – that claim to be from the sending domain.

Reporting

DMARC also enables a sending domain to request that participating email providers send it automatically generated reports about authentication results, thereby enabling the sending domain to monitor whether its SPF and DKIM policies are working properly.

In addition to monitoring proper configuration, this is valuable information one would not normally receive: if an attacker spoofs your domain, they are not likely to copy you on the spoofed email.

More detailed information about DMARC can be found in SP 800-177, section 4.6 and RFC 7489.

What are DMARC reports?

DMARC reports are summaries of email authentication results that are automatically sent by participating email providers. They detail what the email provider saw from your domain over a given period of time, and facilitate the process of graduating to p=reject.

There are two kinds of reports:

  1. aggregate reports
  2. failure reports (sometimes called forensic reports)

Both reports provide information like the sending and receiving email domains, the DMARC policy that the email recipient discovered and applied, the identifier that was evaluated by SPF and/or DKIM and whether it was in alignment, the number of successful authentications, and the totals for all messages received. Aggregate reports are normally delivered once daily from mail receivers, whereas failure reports are sent immediately after an authentication failure. Failure reports include additional information about identity alignment, and can even include much of the body of the email and email headers; this can lead to an unintended exposure of private information. Failure reports are only sent by a handful of ISPs, none of which are US-based.

See the Compliance Guide for more info.


HTTPS

Background

In 2015, the White House Office of Management and Budget (OMB) issued memorandum M-15-13, “A Policy to Require Secure Connections across Federal Websites and Web Services”, and a companion site at https.cio.gov. This policy requires all publicly-accessible Federal websites and web services to enforce the use of Hypertext Transfer Protocol Secure (HTTPS), and to use HTTP Strict Transport Security (HSTS).

The memo details why HTTPS and HSTS are so important:

The unencrypted HTTP protocol does not protect data from interception or alteration, which can subject users to eavesdropping, tracking, and the modification of received data… Unencrypted HTTP connections create a privacy vulnerability and expose potentially sensitive information about users of unencrypted Federal websites and services. 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.

HSTS …instruct[s] compliant browsers to assume HTTPS going forward. This reduces insecure redirects, and protects users against attacks that attempt to downgrade connections to plain HTTP.

Over the last two years, this policy’s implementation has enabled the federal government to outpace the private sector in the deployment of HTTPS.

Moving Ahead

M-15-13 also contemplates that “[p]rotocols and web standards improve regularly” and that “Federal websites and services should deploy HTTPS in a manner that allows for rapid updates to certificates, cipher choices (including forward secrecy), protocol versions, and other configuration elements.”

BOD 18-01 directs agencies to make more progress on HTTPS and HSTS deployment, including by removing support for known-weak cryptographic protocols and ciphers. These are:

Protocols

Ciphers

BOD 18-01 requires that these protocols and ciphers cease being offered on internet-facing web and email servers.

Preloading

The directive also requires that agencies identify and provide a list to DHS of agency second-level domains that can be HSTS preloaded. Agencies should review their list of second-level domains (including any not yet using the .gov top-level domain, as required by M-17-06) and analyze which can be preloaded.

See the Compliance Guide below for more info.


Compliance Guide

This page provides implementation guidance for Binding Operational Directive 18-01 (BOD 18-01), which requires certain email and web security actions from Federal agencies.

Checklist

Frequently Asked Questions

Answers to other common compliance questions appear below.

What is the scope of BOD 18-01?

The Directive applies to internet-facing agency information systems, which encompasses those systems directly managed by an agency as well as those operated on an agency’s behalf. Its primary focus is on agency mail and web infrastructure, regardless of domain suffix.

What is a second-level domain?

A “second-level domain” is the domain name your organization has directly registered, inclusive of the top-level domain. In the example www.dhs.gov, the second-level domain is dhs.gov.

Some examples of top-level domains (TLDs; sometimes called “public suffixes”) are .gov, .mil, .fed.us, .org, or .com. OMB memorandum M-17-06 requires that federal agencies use the .gov or .mil TLDs.

How does the web security requirement in BOD 18-01 differ from M-15-13?

BOD 18-01 incorporates parallel language to M-15-13 with regard to HTTPS deployment. The Compliance Guide at https.cio.gov should be consulted in implementing HTTPS and HSTS.

BOD 18-01 also mandates two additional steps:

  1. The disabling of old SSL versions (SSLv2 and SSLv3) and legacy cipher suites (3DES and RC4). In 2014, NIST marked SSLv2/v3 and RC4 as “not approved”, and in 2017, NIST urged all users of 3DES to migrate as soon as possible.
  2. Requiring a review of second-level domains that can be submitted for HSTS preloading and to submit this list to DHS.

Preloading a domain enforces the use of HTTPS across an entire zone, and is technical compliance with the HTTPS usage requirements of BOD 18-01. Preloading allows agencies to avoid inventorying and configuring an HSTS policy for every individual subdomain, though this necessarily impacts all subdomains present on the domain, including intranet subdomains. Thus, all subdomains will need to support HTTPS in order to remain reachable for use in major browsers. Even with these two obstructions, preloading a domain can be a reality with coordinated effort.

Second-level .gov domains that are only used to redirect visitors to other websites and are not used on intranets are excellent preloading candidates. However, DHS strongly recommends that federal agencies perform a thorough evaluation of those domains that are highly trafficked or otherwise have significant value. Those are likely to be the domains that citizens and intra-agency users stand to benefit most from the always-HTTPS approach that preloading provides.

My device is HTTPS already and doesn’t natively support HSTS. Can DHS mark this a false positive?

No. HSTS is intended to protect users, not servers. Even if a device is HTTPS-only and doesn’t respond over port 80, users are at risk from insecure redirects. Without HSTS, clients may still issue HTTP requests even when the server does not support them, and an attacker with an on-path vantage point can redirect or spoof these requests for malicious purposes.

The best mitigation for this threat is to preload your domains.

We encourage you to request that your vendors support HSTS in their products. Some federal agencies have had success in these requests, and DHS is happy to assist you in the request.

How should the list of second-level domains to be preloaded be shared with DHS?

You are encouraged to preload your domains yourself and then to report the set of preloaded domains to DHS in your Agency Plan of Action.

Where preloading directly is infeasible (for example, when HTTP is only served on subdomains, not on the ‘www’ of the base domain or at the domain root directly), you should include domains to preload in your Agency Plan of Action and DHS will coordinate the preloading with the DotGov program.

What process should be followed in order to implement email authentication?

For all second-level domains and all mail-sending hosts generally, make a plan to implement SPF, DKIM (mail-senders only), and DMARC, with a goal of setting p=reject on all second-level domains.

NIST Special Publication 800-177, section 4.6.1 recommends:

When implementing email authentication for a domain for the first time, a sending domain owner is advised to first publish a DMARC [resource record] with a “none” policy before deploying SPF or DKIM. This allows the sending domain owner to immediately receive reports indicating the volume of email being sent that purports to be from their domain. These reports can be used in crafting an email authentication policy that reduces the risk of errors.

See Resources for implementation case studies.

How should DMARC be deployed?

DMARC was developed to enable cautious deployment. While the standard has three policy states (none, quarantine, and reject), it also has a pct, or percent, option that a domain owner can use to tell recipients what volume of messages should have the policy applied. When pct is left unspecified, the default value of 100% is used.

Rolling DMARC out incrementally by increasing the policy state and percent value over time, while carefully monitoring daily DMARC aggregate reports, is a good strategy to get to p=reject.

One Google support document offers a nominal deployment:

  1. Monitor all (p=none)
  2. Quarantine 1%
  3. Quarantine 5%
  4. Quarantine 10%
  5. Quarantine 25%
  6. Quarantine 50%
  7. Quarantine all
  8. Reject 1%
  9. Reject 5%
  10. Reject 10%
  11. Reject 25%
  12. Reject 50%
  13. Reject all

By the DMARC deadline, p=reject must be at pct=100 either explicitly or implicitly.

Why is p=reject required?

A primary goal of the Directive is to make it hard to successfully spoof government services. A DMARC policy of p=none allows you to gather insight into those systems that are sending mail using your domain – including imposters. But p=none doesn’t actually delay or stop unauthenticated mail from being delivered. It should be viewed as a temporary state on the path to higher levels of enforcement.

p=quarantine is where a domain’s policy starts to be enforced. This means that, for most users, unauthenticated mail from a domain with p=quarantine would be placed in a junk email folder. Since the message is delivered, though, a user could still find it and be harmed by it.

Only a policy of p=reject blocks delivery of unauthenticated message completely.

Does using p=reject mean that leads or anonymous sources may not be able to send us emails?

No. Having legitimate email inadvertently filtered is a common concern for any organization employing traditional spam-filtering technologies. DMARC is fundamentally different from spam-filtering in how it protects from malicious email, however.

DMARC protects a domain from being impersonated without detection. It allows a domain owner to specify the authentication requirements for any email that uses their domain name, and tells a receiving email server what to do if the message fails to authenticate properly.

An email from a lead or anonymous source to e.g, fed@agency.gov is not implicated by the DMARC policy at agency.gov unless the source is sending it so as to appear as though it was coming from agency.gov. This is an email that could be very harmful: it’s the equivalent of someone calling you while credibly impersonating your boss – and it can be stopped by sending a policy of p=reject.

In other words, your organization’s DMARC policies, as set in public DNS, have no effect on the deliverability of email coming from domains you don’t own. People who seek to email anonymously can still do so, unaffected by your domain’s DMARC policy.

What are the ramifications of setting subdomain policies?

Subdomains can have their own p= policy set (e.g., at _dmarc.subdomain.domain.gov), but otherwise they inherit the p= policy set at the second-level domain or, if present, the subdomain policy (sp=) at the second-level domain.

Setting p=reject at the second-level domain is intended by the Directive so as to cascade throughout the zone, protecting all subdomains against spoofing. This is thwarted, though, when a policy weaker than p=reject is set on any subdomain directly or via ansp= tag set on a second-level domain.

While you work to properly authenticate email sent from subdomains, it is reasonable to set weaker-than-reject p= policies on subdomains or by setting an sp= on second-level domains. However, at one year after BOD issuance, the second-level domain must be at p=reject with no sp= policies set at the second-level domain nor subdomains with explicit policies less restrictive than reject.

What should be done with domains that do not send mail?

Even if you do not send mail from your domain, anyone can spoof it to give the appearance that mail is coming from you. Setting a DMARC policy of p=reject signals to recipient mail servers to reject any email purportedly sent from the domain, protecting your reputation and your stakeholders from likely malicious actors.

The following steps should be taken for second-level domains that don’t send mail:

"v=spf1 -all"

DMARC policies set at a second-level domain act as a wildcard, covering subdomains generally, including non-mail-sending domains. When a domain’s DMARC policy is set to p=reject, it is not necessary to specify SPF “null records” on every active domain in the zone, though doing so is not harmful.

How can I receive DMARC reports?

You can configure a target address for DMARC report delivery by specifying for rua= (aggregate) or ruf= (failure) DMARC tags. You should receive reports from participating email providers within 48 hours.

Where should DMARC reports be sent?

Specify an email address where DMARC reports can be reviewed regularly. A DMARC record can indicate multiple addresses where reports should be sent; see RFC 7489, section 6.2.

A DMARC record that follows this recommendation, as set on _dmarc.example.gov, looks like this:

"v=DMARC1; p=none; rua=mailto:reports@example.gov;"

This DMARC record has a policy of none and requests that DMARC aggregate reports be sent to reports@example.gov. These reports, as well as failure reports, should be utilized to assist in the process of getting to p=reject.

Commercial services exist that help derive intelligence from DMARC reports, though their use is not required to receive or read DMARC reports.

DHS DMARC reporting location

Federal agencies must add DHS NCCIC as an aggregate report recipient. The address that must be included is reports@dmarc.cyber.dhs.gov.

Sending DMARC reports to more than one location

You are encouraged to receive your own DMARC reports in addition to sending them to DHS.

When crafting this portion of the DMARC record, take care that a) only one rua= is defined, b) each address has its own mailto:, and c) email addresses are separated by a comma. The rua portion of the DMARC policy record could look like the following:

rua=mailto:dmarc-reports@example.gov,mailto:reports@dmarc.cyber.dhs.gov

You should also note that while receivers must support the ability to send to at least two reporting addresses, a limit can be imposed beyond two. See RFC 7489, section 6.2, or an example at appendix B.2.4.

Sending DMARC reports to a different domain than your own

Sending DMARC reports to a domain different than the one requesting reports requires additional configuration at the intended recipient’s DNS. In order to mitigate a denial of service threat whereby someone could request DMARC reports be sent to arbitrary domains, an intended recipient of DMARC reports must signal its willingness to accept another domain’s reports with a DNS TXT record with the value v=DMARC1 at a URI that follows this syntax:

<original-sender-domain>._report._dmarc.<mailto-domain>

For example, when mail is delivered that appears to come from example.gov, the recipient mail server queries for a TXT record at _dmarc.example.gov. It might find something like this:

_dmarc.example.gov. IN TXT "v=DMARC1; p=reject; rua=mailto:reports.example.net"

Here, the aggregate report for example.gov has been requested to be sent to example.net. Seeing that these are different domains, the recipient mail server will query for a TXT record at example.gov._report._dmarc.example.net. If it finds a TXT record starting with the value v=DMARC1, then example.net will be considered a legitimate recipient for example.gov’s DMARC reports.

More details can be found at SP 800-177, section 4.6.6, and RFC 7489, section 7.1 (with Appendix B.2.3).

Can email authentication hinder my organization’s ability to deliver email?

Yes. You should thoughtfully deploy these technologies and plan your implementation carefully.

In particular, deploying DKIM and DMARC without adequate planning can cause negative impacts:

Does the Directive require email authentication checks before mail delivery?

BOD 18-01 requires email authentication be performed by sending domains. Evaluating inbound email against the sending domain’s SPF/DKIM/DMARC records are strongly recommended, but not explicitly required.

Does the Directive require the use of DKIM?

BOD 18-01 requires federal agencies to set a DMARC policy of p=reject, which can be achieved without the use of DKIM. However, doing so is ultimately a policy decision for your organization to decide upon.


Resources

Read

Watch

Tools

Tutorials

Get Help

Contribute