Skip to main content

Sharing Links Over Email: Security @ ICANN

Many of you have read earlier posts by our CIO Ashwin Rangan regarding our ongoing improvements to ICANN's overall cybersecurity. This is a brief update on some recent security changes we've made to email services, some of which will be noticeable to many in the ICANN community.

As you are all aware, phishing poses the most pervasive threat to all organizations defending digital assets. Despite their best efforts, many organizations (using technical controls or awareness training) are finding that phishing continues to be the primary vector by which attackers gain a foothold into corporate networks.

Spear phishing, the individually customized approach to phishing, is even more effective and harder to spot.  Spear phishing emails can lead us to click hostile links or open file attachments that lead to compromise, data theft or other losses.

The rapidly emerging sophistication and proliferation of ransomware has also captured recent headlines. The vast majority of ransomware is delivered via phishing messages, with either malicious links or file attachments. As such, defenses used against ransomware largely hinge on email security measures.

So, what security-related email changes have we made here at ICANN, and how do they effect the community?

Changes of Interest to ALL Community members:

The first change is quite simple, and one that many organizations have already made. Messages received from outside our domain now have [EXTERNAL] prepended to the subject line. You may see that tag reflected back in email replies from our staff or in messages sent to mailing lists. When you see this new tag, please remember we don't view the community as "external" to ICANN! We are simply reminding staff to handle messages received from outside senders with extra care. Organizations typically use these type of tags to help recipients spot spear phishing messages that might use lookalike domains similar to one of their own. 

The second change is a bit more complicated. You may have recently received a message in a forwarded or 'reply-to' email from ICANN senders and noticed that the URL links contained in the message were rewritten. 

ICANN IT is using a new tool (Proofpoint URL Defense) to help protect email users from malicious URLs in messages. This service scans our incoming email for hyperlinks and rewrites them with special URLs. These new URLs allow Proofpoint to check the original URL before actually sending the reader to that web page. URLs found to be used for malicious purposes (phishing, malware delivery, etc.) are blocked, while other URLs simply remain rewritten.

The rewritten links in HTML emails have the website's domain added in square brackets after the link. In plaintext email the link will be significantly changed with text "https://urldefense.proofpoint.com/v1/url?u=" prepended to the beginning of the link, followed by a string of letters and numbers.

Following these links will take you to the original address, and will not alter your browsers connection to that site unless Proofpoint has determined that site serves malicious content.

This new defense against malicious links (which require URLs to be rewritten) provides ICANN with a much needed extra layer of security. While many of us can spot and avoid some phishing email scams by their subject lines, when we handle large volumes of email within short periods of time, even the best of us will make mistakes. These rewritten links will allow us to detect which malicious links have been followed and respond as quickly and efficiently as possible.  

Of Interest to Network/Email Admins:

ICANN has published records for both its Sender Policy Framework (SPF - see RFC 4408) and Domain-based Message Authentication, Reporting, and Conformance (DMARC see - RFC 7489).  These records help enable the community to identify legitimate email coming from our domain.  We encourage all enterprises receiving mail from our domain to utilize these records and to keep a look out for changes in our DMARC as we move to a stricter record.

For those organizations that use either S/MIME or PGP digital signatures, our staff supports both, and we highly encourage the use of these tools as well.

We have also added Domain Keys Identified Mail (DKIM - see RFC 6376) to our security roadmap for the coming year.

We are all dealing with an increasingly challenging cybersecurity environment. Email-borne threats are prevalent and require greater and greater attention. We ask for your patience with any inconvenience or disruptions that may occur with our normal email messaging as we pursue a more secure approach for our communications.

Comments

    Adam  23:03 UTC on 12 October 2016

    Thanks for the information

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."