CISA Insights

Informed by U.S. cyber intelligence and real-world events, each CISA Insight provides background information on particular cyber threats and the vulnerabilities they exploit, as well as a ready-made set of mitigation activities that non-federal partners can implement. This page is continuously updated to reflect new CISA Insights as they are made available.

Ransomware Outbreak

The Threat and How to Think About It

Ransomware has rapidly emerged as the most visible cybersecurity risk playing out across our nation’s networks, locking up private sector organizations and government agencies alike. And that’s only what we’re seeing – many more infections are going unreported, ransoms are being paid, and the vicious ransomware cycle continues on. We strongly urge you to consider ransomware infections as destructive attacks, not an event where you can simply pay off the bad guys and regain control of your network (do you really trust a cybercriminal?).

CISA's Role as the Nation's Risk Advisor

Helping organizations protect themselves from ransomware attacks is a chief priority for the Cybersecurity and Infrastructure Security Agency (CISA). We have assisted many ransomware response and recovery efforts, building an understanding of how ransomware attacks unfold, and what potential steps you can take to better defend systems. But we also recognize that there’s no such thing as perfect cybersecurity and ransomware infections can still happen, so we’ve also developed recommendations to help organizations limit damage, and recover smartly and effectively.

Ransomware Mitigations to Help you Defend Today and Secure Tomorrow

The below recommendations lay out three sets of straightforward steps any organization can take to manage their risk. These recommendations are written broadly for all levels within an organization. It’s never as easy as it should be, so if you need help, we urge you to reach out for assistance – CISA is here to help, but so is the FBI, numerous private sector security firms, state authorities, and others.

Actions for - Make Sure You're Not Tomorrow's Headline:

  1. Backup your data, system images, and configurations and keep the backups offline
  2. Update and patch systems
  3. Make sure your security solutions are up to date
  4. Review and exercise your incident response plan
  5. Pay attention to ransomware events and apply lessons learned

Actions to Recover If Impacted - Don't Let a Bad Day Get Worse:

  1. Ask for help! Contact CISA, the FBI, or the Secret Service
  2. Work with an experienced advisor to help recover from a cyber attack
  3. Isolate the infected systems and phase your return to operations
  4. Review the connections of any business relationships (customers, partners, vendors) that touch your network
  5. Apply business impact assessment findings to prioritize recovery

Actions to Secure Your Environment Going Forward - Don't Let Yourself be an Easy Mark:

  1. Practice good cyber hygiene; backup, update, whitelist apps, limit privilege, and use multifactor authentication
  2. Segment your networks; make it hard for the bad guy to move around and infect multiple systems
  3. Develop containment strategies; if bad guys get in, make it hard for them to get stuff out
  4. Know your system’s baseline for recovery
  5. Review disaster recovery procedures and validate goals with executives

Please visit the CISA Resource Page on Ransomware for more information. Victims of ransomware should report it immediately to CISA at www.us-cert.gov/report, a local FBI Field Office, or Secret Service Field Office.

This product is provided subject to this Notification and this Privacy & Use policy.

Mitigate DNS Infrastructure Tampering

At-A-Glance Recommendations

  • Review DNS Records
  • Change DNS Account Passwords
  • Add Multi-Factor Authentication to DNS Accounts
  • Monitor Certificate Transparency Logs

Cybersecurity Threat

In late 2018, cybersecurity organizations across the globe started to detect an increase in malicious activity targeting the Domain Name System (DNS) infrastructure on which we all rely. Using common tactics, outlined below, the attackers were able to redirect and intercept web and email traffic, and could have achieved the same for other networked services.

The Cybersecurity and Infrastructure Security Agency (CISA) encourages its State, Local, Tribal and Territorial (SLTT) government partners, as well as private sector owners of critical infrastructure, to use this guide to learn more about this threat and associated mitigation activities. This guidance is derived from Emergency Directive 19-01 – Mitigate DNS Infrastructure Tampering and includes lessons learned and additional considerations for non-federal entities seeking to implement actions in line with federal civilian departments and agencies, as directed by CISA.

Attack Breakdown

How It Works

  1. The attacker begins by compromising user credentials, or obtaining them through alternate means, of an account that can make changes to DNS records. 

  2. The attacker alters DNS records, like Address (A), Mail Exchanger (MX), or Name Server (NS) records, replacing the legitimate address of a service with an address the attacker controls. This enables them to direct user traffic to their own infrastructure for manipulation or inspection before passing it on to the legitimate service, should they choose. This creates a risk that persists beyond the period of traffic redirection. 

  3. Because the attacker can set DNS record values, they can also obtain valid encryption certificates for an organization’s domain names. This allows the redirected traffic to be decrypted, exposing any user-submitted data. Since the certificate is valid for the domain, end users receive no error warnings. 

Why It's Effective

  • Frequently, different domain and DNS records are owned and managed by different parts of an organization. This means that many organizations lack central visibility into all domains that belong to them or associated DNS records. 

  • This decentralization of the DNS ecosystem and the organizational governance processes make it difficult to monitor and secure domains.  

Recommended Actions

To address the significant risks to organizational information and information systems posed by DNS tampering, CISA directed federal civilian agencies to undertake the following series of near-term actions and encourages non-federal organizations to do the same:

Action 1: Review DNS records

  • For all organization owned/managed domains:

    • Review all public domain records with domain registrars to verify the associated NS records are delegated to intended DNS servers; and  

    • Review all DNS records on all authoritative and secondary DNS servers to verify they resolve to their intended destination.  

  • Any discovered discrepancies should be investigated immediately and treated as a potential security incident.  

Action 2: Change DNS account passwords

  • Immediately update passwords for all accounts on systems that can make changes to your organization’s DNS records, including accounts on organization-managed DNS server software, systems that manage that software, third-party DNS operators’ administration panels, and DNS registrar accounts.  

Action 3: Add multi-factor authentication to DNS accounts

  • Implement and enforce multi-factor authentication (MFA) for all accounts on systems that can make changes to your organization’s DNS records including accounts on organization-managed DNS server software, systems that manage that software, third-party DNS operators’ administration panels, and DNS registrar accounts.  

  • If MFA is not supported for records hosted by third party providers, CISA strongly encourages organizations to consider migrating to providers that support strong access controls and MFA.  

  • If MFA is not supported on legacy system hosted by organizations internally, compensating controls can be introduced to temporarily harden access controls (e.g. require physical console access, disable remote access, limit remote access to management network only, etc.). 

Action 4: Monitor certificate transparency logs

  • Monitor Certificate Transparency (CT) log data for newly added certificates issued to organization-owned domains that have not been authorized/requested by the organization.  

Scope of Recommendations

  • The focus of these recommendations is on external/public/internet facing domain and DNS records. The recommendations are not concerned with internal infrastructure. 

  • The scope of these recommendations transcends DNS infrastructure itself and requires a comprehensive approach that includes associated services. To capture this scope, CISA uses the term DNS ecosystem to include: root zones, top level domain registries, domain registrars, domain registrants, and authoritative DNS servers. Disparate organizational units may be responsible for managing these services and successful outcomes depend on their close coordination. 

Lessons Learned and Additional Considerations

Lessons Learned

  • Many organizations lack a DNS-specific policy to guide DNS-related activities at the operational level that specify security protocols and activities related to the protection of the DNS ecosystem. Even basic steps that can be taken to maintain awareness of DNS infrastructure, such as the documentation of a domain inventory, are not consistently or effectively acted upon across organizations.  

  • Organizations need better top-level control of the acquisition, management, and reporting of domains (e.g. preventing anyone with a corporate purchase card from registering a domain). To successfully protect their infrastructure from DNS tampering, it is critical that organizations have accurate and up-to-date inventories of all domain names that are owned or operated on their behalf.

  • Without a clear understanding of an organization’s environment, it is not only difficult to identify anomalies, risks, and misconfigurations but it is impossible to defend against what one does not know. 

Implementation Considerations

  • Performing historical analysis of past record changes (passive DNS) may be prudent, but it will not stop current hijacking from occurring, it may only indicate whether a hijack has occurred in the past.  

  • Certificate Transparency logs record all SSL certificates issued by publicly trusted certificate authorities. While those certificates are not directly issued for DNS services, logs can alert you that an unauthorized certificate was issued for a domain you manage. To take full advantage of CT log monitoring, organizations must 1) have a comprehensive inventory of domains they manage, and 2) the ability to confirm that a certificate request was actually authorized by your organization. 

  • In large organizations with multiple operating divisions, the process of obtaining a certificate may not be centrally managed, and a single entity may not be aware that a given certificate was requested.  

  • To monitor CT logs, organizations may use various free or commercial CT monitoring services. 

Resource Considerations

  • From a federal perspective, gaining central visibility into all domains owned by an organization proved to be the most labor intensive and challenging process. Organizations with a strong grasp on all domain related records and/or central visibility had to invest significantly less effort to meet the same requirements. A coordinated effort by all organizational units throughout the enterprise is essential for a successful outcome. 

  • Organizations with a large number of domain names and domain name records may want to prioritize domain names and records associated with key services offered to organizational users (for example, websites that are central to the organization’s mission, MX records, or other services with high utilization).  

Helpful Links and Reference Materials

CISA Emergency Directive 19-01 – Mitigate DNS Infrastructure Tampering and FAQ: https://cyber.dhs.gov/ed/19-01/  

CISA Current Activity: DNS Infrastructure Hijacking Campaign: https://www.us-cert.gov/ncas/current-activity/2019/01/10/DNS-Infrastructure-Hijacking-Campaign 

Sources of Certificate Transparency (CT) logs (and passive DNS records):

https://www.entrust.com/ct-search 

https://crt.sh 

https://sslmate.com/certspotter 

https://transparencyreport.google.com/https/certificates?hl=en 

Auditing DNS records and Certificate Transparency (CT) logs using Splunkhttps://www.splunk.com/blog/2019/01/25/cisa-emergency-directive-19-01-doing-things-the-easy-way-in-splunk.html

For guidance on MFA, organizations should consult National Institute of Standards and Technology (NIST) Special Publication 800-63B Digital Identity Guidelines Authentication and Lifecycle Management: https://csrc.nist.gov/publications/detail/sp/800-63b/final  

When utilizing MFA, organizations should consider using additional factors that are resilient to phishing. Consistent with NIST SP 800-63B, Short Message Service (SMS)-based MFA is not recommended. 

 This product is provided subject to this Notification and this Privacy & Use policy.

Remediate Vulnerabilities for Internet-Accessible Systems

At-A-Glance Recommendations

  • Ensure your vulnerability scanning service is scanning all Internet-accessible IP addresses
  • Notify the scanning service of any modifications to your organization's Internet-accessible IPs
  • Ensure the scanning service provides at least weekly scanning results
  • Coordinate with system owners to remediate vulnerabilities

Cybersecurity Threat

Adversaries operating in cyberspace can make quick work of unpatched Internet-accessible systems. Moreover, the time between an adversary’s discovery of a vulnerability and their exploitation of it (i.e., the ‘time to exploit’) is rapidly decreasing. Industry reports estimate that adversaries are now able to exploit a vulnerability within 15 days (on average) of discovery. After gaining entry into information systems and networks, these adversaries can cause significant harm.

Internet-accessible information systems include any system that is globally accessible over the public internet (i.e., has a publicly routed internet protocol (IP) address or a hostname that resolves publicly in DNS to such an address) and encompass those systems directly managed by an organization, as well as those operated by a third-party on an organization’s behalf. As organizations continue to expand their Internet presence through increased use and operation of interconnected and complex Internet accessible systems, it is more critical than ever to rapidly remediate vulnerabilities inherent to these systems. Failure to do so could allow malicious actors to compromise networks through exploitable, externally-facing systems.

The Cybersecurity and Infrastructure Security Agency (CISA) encourages its State, Local, Tribal and Territorial (SLTT) government partners, as well as private sector owners of critical infrastructure, to use this guide to learn more about this threat and associated mitigation activities. This guidance is derived from Binding Operational Directive 19-02 – Vulnerability Remediation Requirements for Internet-Accessible Systems and includes lessons learned and additional considerations for non-federal entities seeking to implement actions in line with federal civilian departments and agencies, as directed by CISA.

Recommended Actions

To ensure effective and timely remediation of vulnerabilities identified through vulnerability scanning, organizations should undertake the following actions:  

Action 1: Ensure your vulnerability scanning service is scanning all Internet-accessible IP addresses

  • Create and maintain an asset inventory of all such IPs belonging to your organization.  

Action 2: Notify the scanning service of any modifications to your organization's Internet accessible IPs

  • This includes newly acquired IPs or re-assigned IPs that are no longer part of your organization's asset inventory. 

Action 3: Ensure the scanning service provides at least weekly scanning results

Action 4: Coordinate with system owners to remediate vulnerabilities

  • CISA recommends the following remediation timelines:  

    • Critical vulnerabilities should be remediated within 15 calendar days of initial detection. 

    • High vulnerabilities should be remediated within 30 calendar days of initial detection. 

  • If vulnerabilities cannot be remediated within the recommended timeframes, develop a remediation plan for action and coordination across the organization. The remediation plan should include  

    • Vulnerability remediation constraints 

    • Interim mitigation actions to overcome constraints 

    • Final actions required to remediate vulnerability 

Lessons Learned and Additional Considerations

Lessons Learned

  • The decentralization of organizations and their governance processes makes it difficult to coordinate the remediation of vulnerabilities. Network owners should be aware of who is operating their respective networks, if not done in-house.
  • Without a clear understanding of an organization’s internet-accessible footprint, it is not only difficult to identify anomalies, risks, and misconfigurations but also it is impossible to defend against what one does not know.
  • Many organizations lack robust patch and configuration management policies and procedures to guide the coordination of vulnerability management-related activities at an operational level.
  • Historically, most vulnerabilities identified by CISA are related to unsupported operating systems that cannot receive patched or upgraded (secure) software. This is largely due to the prevalence of legacy systems across all industries and sectors, some of which perform mission critical functions. The continued presence of end-of-life (EOL) systems is mostly due to the budgetary constraints inherent in replacing large amounts of EOL systems, often at the reduced funding levels of sub-organizations.

Implementation Considerations

  • Establishing a coordination POC can help ensure the streamlined dissemination of vulnerability information to all sub-organizations. A coordination POC can also help resolve false positive claims and unnecessary remediation actions. 

    • CISA’s process for resolving false positives includes:  

      1. Submit an email to your organization’s coordination POC with analysis and supporting evidence for determination (for example, a screenshot of the IP address and operating system). CISA also utilizes a False Positive Assertion form for system owners to fill-out and submit to the coordination POC.  

      2. The coordination POC facilitates review of the evidence and analysis to validate the assertion. This does not include exploiting a vulnerability, but may include actively sending packets to the host in question. If the analysis confirms the assertion, the vulnerability is marked as a false positive. 

      3. False positive status expires 365 days after designation and personnel are required to re-submit evidence on an annual basis to confirm the vulnerability remains a false positive. 

  • Manage and prioritize cybersecurity risk appropriately within your environment. The nuances of each organization’s environmental risk factors and mitigating controls is different. Prioritize certain vulnerabilities and devices over others in line with your organization’s existing security baselines. 

  • Apply additional parameters, rules, and internal policy decision points as necessary, which may affect the acceptable timeframes to remediate specific types of vulnerabilities or vulnerabilities affecting certain types of devices. For example, organizations should consider the impact the exploitation of a vulnerability may have if an Internet-accessible IP is associated with a High Value Asset (HVA) or Mission Essential System (MES).  Likewise, organizations should consider how many assets are affected by a specific vulnerability type and how long vulnerabilities have existed. 

  • Continuously analyze threat information, vulnerability information, and engage sub-organizations to further prioritize actions which may go beyond the defined scores to indicate ‘critical of critical’ vulnerabilities. In these instances, provide alerts to sub-organizations to ensure adequate steps are being taken across the organization. 

  • Not every vulnerability will require immediate action, nor is it prudent to apply patches without first analyzing and testing to minimize disruption to network operations. In these cases, organizations should clearly articulate the rationale for not remediating the vulnerability to the group coordinating organization-wide vulnerability management.  

  • Where patching is not possible due to certain limitations, network segregation is highly recommended to limit exposure of the vulnerable system or host. 

Vulnerability Scanning Considerations

  • Ensure a service agreement is established and signed between your organization the scanning service provider to outline the scope and parameters of scanning. 

  • Include all in-scope IPs from all aspects of the organization (i.e., sub-organizations) in the IP asset inventory to ensure scanning and vulnerability identification across the organization. If ports aren’t normally open to the general public (e.g. only certain whitelisted IPs can connect), you should still ensure the IP is included in the scanning scope so the scanning service can act as a double-check on that rule for you. 

  • Ensure scanning access by removing the service’s source IP addresses from block lists. This allows your organization to properly triage and respond to alerts generated by your Security Information and Event Management (SIEM). These addresses may change without prior notice, so CISA recommends regular monitoring of any provided source IP list.  

  • Ensure Internet Service Providers (ISPs), Cloud Service Providers (CSPs), and other shared service providers are aware of your organization’s requirements for remediating internet-accessible vulnerabilities. Ensure service providers are meeting or exceeding remediation requirements.  

  • Do not grant preferential treatment (e.g. explicitly whitelisting or opening any ports/services other than what is normally available for your systems) for the scanning. This allows the scanning service to find and report on vulnerabilities from a perspective similar to that of an attacker. However, scanning services are focused on identifying exposed vulnerabilities prior to their exploitation, and due to timing and urgency considerations, they usually make no attempt at stealth, which may sometimes trigger technical controls that an attacker, using more conservative tactics, might not. Should this occur, remove network blocks and let the scanning service know that their scans were blocked as well as that you have corrected it so they can jumpstart scanning on the particular IPs again, if necessary. 

  • Include internet-accessible applications in your scanning scope even if only available to your organization. The scope should include all of your static, public IP addresses that are managed by or on behalf of your organization. Do not include private IPs from systems accessible only through your organization’s intranet.  

  • CISA offers a no-cost service comprising vulnerability scanning of static IPv4 IP addresses to identify vulnerabilities on Internet-accessible systems. SLTT governments and private entities should consider taking advantage of this service in addition to periodic tests conducted by network administrators. 

  • Non-federal organizations can opt to participate in the CISA vulnerability scanning program by sending a request to ncats_info@hq.dhs.gov

Resource Considerations

  • Establishing a vulnerability coordination POC and aligning resources to address identified vulnerabilities detected on Internet-accessible systems is only the beginning and most inexpensive aspect of vulnerability management. 

  • The next step is implementing a vulnerability and configuration management program to enforce consistent patch management across all hosts within the network environment. This should start with those systems that have critical or prioritized vulnerabilities discovered in the vulnerability scan. When possible, remove end-of-life products from the network. 

Helpful Links and Reference Materials

CISA Binding Operational Directive 19-02 – Vulnerability Remediation Requirements for Internet-Accessible Systems and FAQ: https://cyber.dhs.gov/bod/19-02/ 

CISA Blog Post on BOD 19-02: https://www.dhs.gov/cisa/blog/2019/04/29/cisa-releases-binding-operational-directive-new-requirements-remediating 

For guidance on Enterprise Patch Management Technologies, organizations should consult National Institute of Standards and Technologies (NIST) Special Publication 800-40 Rev. 3 Guide to Enterprise Patch Management Technologies: https://csrc.nist.gov/publications/detail/sp/800-40/rev-3/final 

This product is provided subject to this Notification and this Privacy & Use policy.

Secure High Value Assets (HVAs)

At-A-Glance Recommendations

  • Establish an organization-wide HVA governance program
  • Identify and prioritize HVA information systems
  • Consider the interconnectivity and dependencies of HVA systems when determining which systems are HVAs
  • Develop a methodology for prioritizing HVAs based on criticality and mission importance
  • Develop an assessment approach based on HVA prioritization
  • Ensure timely remediation of identified vulnerabilities

Cybersecurity Threat

A High Value Asset (HVA) is information or an information system that is so critical to an organization that the loss or corruption of this information or loss of access to the system would have serious impact to the organization’s ability to perform its mission or conduct business. These assets, systems, and datasets may contain sensitive controls, instructions or data used in critical operations, or they may house unique collections of data. These sensitivities make HVAs of particular interest to criminal, politically-motivated, or state-sponsored actors for either direct exploitation of the data or to cause a loss of confidence by the public. 

To counter dynamic threats to the security and resilience of HVAs, it is essential that organizations take a more comprehensive view of the risk they pose and the information and information systems they target. 

The U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) encourages its State, Local, Tribal and Territorial (SLTT) government partners, as well as private sector owners of critical infrastructure, to use this guide to learn more about the threat to HVAs and associated mitigation activities. This guidance is derived from Binding Operational Directive 18-02 – Securing High Value Assets and includes lessons learned and additional considerations for non-federal entities seeking to implement actions in line with federal civilian departments and agencies, as directed by CISA

Recommended Actions

To address the significant risks to HVAs, CISA directed federal civilian agencies to undertake the following series of actions and encourages non-federal organizations to do the same. These recommendations address the identification, categorization, and prioritization of HVAs. They focus on an assessment approach to identify and prioritize risks and weaknesses for timely mitigation and architectural enhancements based on the assessment results. 

Action 1: Establish an organization-wide HVA governance program

  • Organizations should take a strategic, enterprise-wide view of cyber risk that unifies the effort to protect HVAs against evolving cyber threats. Organizations should establish an office, team, or other governance structure to enable the incorporation of HVA activities (e.g., assessment, remediation, incident response) into broader planning activities for information system security and privacy management, such as Enterprise Risk Management and Contingency Planning. 

Action 2: Identify and prioritize high value asset information systems

  • The following categories are useful in identifying HVAs. Organizations can determine what information systems they have that fall into one or both of these categories.  

    • Information Value - the data the system processes, stores, or transmits is of high value to the organization and/or adversaries; and 

    • Mission Essential - the owning organization cannot accomplish its mission essential functions within the expected timeliness without this information system.

Action 3: Consider the interconnectivity and dependencies of HVA systems when determining which systems are HVAs

  • For example, if the authentication solution for an HVA is the organization’s centralized Active Directory solution then the Active Directory solution may also be considered an HVA due to critical dependency.  

  • Consider dependent and interdependent systems that can impact the operations of an HVA and its ability to perform a mission.  

  • Protect the dependent and interdependent systems at the same level as the primary systems.  

Action 4: Develop a methodology for prioritizing HVAs based on criticality and mission importance

  • A prioritized HVA list can be used by the organization to prioritize monitoring, assessment, and contingency actions across the organization’s operational functions.   

  • Identify and prioritize the HVAs so that everyone in the organization understands the most important systems.  

  • Ensure that the most important systems receive the highest priority of support, funding, and operations to keep the mission going.  

Action 5: Develop an assessment approach based on HVA prioritization

  • Organizations should develop an assessment approach for their HVAs based on the prioritization. For example, an independent third-party contractor assesses the top 50% of the systems and the bottom 50% of the systems are self-assessed by internal staff. Organizations should determine the best approach for assessments based on their risk management appetite/tolerance. 

  • This should include implementing an HVA organizational risk assessment where all HVA systems receive assessments at least once every three years based on risk. 

  • Performing regular information security checks against these HVAs is critical in ensuring that the systems and information are protected at the appropriate levels commensurate with risk.   

Action 6: Ensure timely remediation of identified vulnerabilities

  • Organizations should make efforts to remediate any assessment risks/weaknesses within 30 days. 

  • If remediation cannot be completed within 30 days, a detailed remediation plan should be developed and tracked to completion.  

Helpful Links and Reference Materials

CISA Binding Operational Directive 18-02 - Securing High Value Assets: https://cyber.dhs.gov/bod/18-02/ 

CISA Binding Operational Directive 16-01 - Securing High Value Assets (Revoked):  https://cyber.dhs.gov/bod/16-01/ 

DHS, Securing High Value Assets: https://www.dhs.gov/sites/default/files/publications/Securing%20High%20Value%20Assets_Version%201.1_July%202018_508c.pdf 

DHS, High Value Asset Control Overlay: https://www.dhs.gov/sites/default/files/publications/HVA%20Control%20Overlay%20v1.0_0_0.pdf 

The Office of Management and Budget (OMB), Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program: https://www.whitehouse.gov/wp-content/uploads/2018/12/M-19-03.pdf 

The Office of Management and Budget (OMB), Managing Information as a Strategic Resource: https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf 

This product is provided subject to this Notification and this Privacy & Use policy.

Enhance Email and Web Security

At-A-Glance Recommendations

  • Adopt a minimum DMARC policy of "p=none"
  • Implement HTTPS with HSTS across all external-facing domains
  • Disable weak encryption standards for web and email
  • Maintain ongoing visibility of DMARC findings and reports

Cybersecurity Threat

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.  

The Cybersecurity and Infrastructure Security Agency (CISA) encourages its State, Local, Tribal and Territorial (SLTT) government partners, as well as private entities, to use this guide to learn more about this threat and associated mitigation activities. This guidance is derived from Binding Operational Directive 18-01 – Enhance Email and Web Security and includes lessons learned and additional considerations for non-federal entities seeking to implement actions in line with federal civilian departments and agencies, as directed by CISA

Attack Breakdown

How It Works

Email

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

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 organizations or members of the public might receive spoofed emails, perceive them to be from an authoritative 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. 

Near-Term Recommended Actions

To address the significant risks to organizational information and information systems posed by phishing emails and use of the unencrypted HTTP protocol, CISA directed federal civilian agencies to undertake the following series of near-term actions and encourages non-federal organizations to do the same:  

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 doesn’t 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 an organization 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. 

Actions to Enhance 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. 

  • Organizations should consider progress on HTTPS and HSTS deployment, such as removing support for known-weak cryptographic protocols and ciphers.  

  • According to CISA vulnerability scanning data, 7 of the 10 most common vulnerabilities seen across observed networks at the time of issuance of Binding Operational Directive 18-01 would be addressed through implementing the recommended actions in this ACR related to web security. 

Where to Get Started

  1. 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 centralized body location as a recipient of DMARC aggregate reports. 

    • Set a DMARC policy of “reject” for all second-level domains and mail-sending hosts. 

  2. 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 centralized body charged with managing these recommendations. 

    • Consider drafting a report to the leadership of the centralized body charged with managing these recommendations on the status of implementation. 

    • Collect feedback and input from partner equities before release to avoid vendor constraints during implementation.  

    • Ensure validating authority and its mechanisms are sound and in place before release to track compliance to successful implementation. 

    • Send all sub-organizations a weekly scorecard to drive competition amongst the participants. 

Ongoing Recommended Actions

  • Perform extensive outreach and support for technical as well as implementation questions. 

  • Host implementation events and technical exchanges to provide additional guidance on implementation.  

  • Send out scorecards weekly to leadership for awareness and to motivate improvement.  

  • Develop public-facing website to provide guidance and FAQs. 

  • Identify non-compliance for follow-on conversations. 

  • Develop a central reporting location for all DMARC reports, and provide analysis to all equities.  

Lessons Learned and Additional Considerations

Lessons Learned

  • Due to a general misunderstanding about how DMARC works, and the potential fear of “missing” emails, the centralized body charged with managing the recommendations should create guidance to share with non-technical staff. 

  • Many organizations 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. 

  • Organizations need higher-level governance to guide their actions concerning these standards. Future changes in an environment could result in increased vulnerability. 

  • Organizations should be cautious 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. 

Implementation Considerations

  • The challenges around “indirect email flows,” where email is sent via intermediaries (mailing lists, account forwarding) is recognized as an issue and discussed further in the references below.  

  • There is a significant vendor constraint in disabling 3DES in mail environments. 

  • Be aware of potential issues with scanning sites that require authentication. 

  • Have a firm understanding of inventory/environment before release. 

  • Establish internal success metrics before release. 

  • Entities with consolidated IT organizations are more efficient at implementation. 

Resource Considerations

  • Many organizations, particularly smaller ones, may lack DMARC expertise and require support in order to implement DMARC

  • Reading and understanding DMARC reports is extremely difficult without a tool.  

  • Implementing the actions recommended in this guide may result in budgetary and/or contractual/vendor implications. 

Helpful Links and Reference Materials

CISA Binding Operational Directive 18-01 - Enhance Email and Web Security and FAQ: https://cyber.dhs.gov/bod/18-01/  

UK National Cyber Security Centre (NCSC) MailCheck GitHub Repository: https://github.com/ukncsc/mail-check  

ElasticMARC - DMARC Aggregate Report Digest and Analysis for Windows Utilizing the Elastic Stack GitHub Repository:  https://github.com/wwalker0307/ElasticMARC  

Dmarcian XML to Human Converter:  https://dmarcian.com/xml-to-human-converter/  

DMARC.org + Code and Libraries Page:  https://dmarc.org/; https://dmarc.org/resources/code-and-libraries/  

Global Cyber Alliance – Benefits of Email Authentication and DMARC TXT Records: https://dmarc.globalcyberalliance.org; https://dmarc.globalcyberalliance.org/resource/dmarc-txt-records-what-we-discovered/  

Authenticated Received Chain (ARC) Mail Forwarding Guidance:  http://arc-spec.org/   

For further guidance, organizations should consult National Institute of Standards and Technology (NIST) Special Publication 800-177 Trustworthy Email: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177.pdf

This product is provided subject to this Notification and this Privacy & Use policy.

Was this document helpful?  Yes  |  Somewhat  |  No