Since 2015, banks have had the ability to obtain Internet domains that end in .BANK instead of the more common .COM or .NET domains. As the popularity of the new .BANK top level domain increases, we are receiving more questions asking if banks should consider moving to the new domain. This week, we will look at what security improvements a .BANK domain will provide and whether these improvements can be achieved on other domain types.
- Reputation: The largest benefit of obtaining a .BANK domain is reputational, as the registrars will only issue these domains to those in the banking industry. Someone doing business with an organization using a .BANK domain will theoretically know that it is actually a regulated bank, and that the owner of the domain had to comply with the security requirements of the domain. Whether this is a true benefit to your bank depends on whether you believe that consumers will understand the difference between a .BANK and any other type of domain.
- DNS Protection: The Internet is based on IP addresses. When someone types a URL in a browser, their computer needs to know the IP address of the URL to get to the site. DNS is the Internet service that translates URLs for a domain into IP addresses, and an attacker who gains control of a DNS service can redirect website URLs to their own malicious servers. The .BANK domain tries to reduce this risk by requiring that the bank use a DNS service which is also inside the .BANK domain and complies with defined security requirements. While the .BANK domain requirements help take the guesswork out of DNS security, most of these requirements can also be put into place on any domain that your bank owns.
- Encryption: The owner of a .BANK domain is required to have a digital certificate, and is required to support TLS 1.1 or above. While these are good requirements to have, they are not unique to the .BANK domain. Every bank should already have these controls in place regardless of domain.
- Email Authentication: Proponents of the .BANK domain promise less phishing for those on the domain. What they are really saying is that, because of some of the email authentication requirements imposed by the .BANK domain, your customers should receive fewer phishing emails from your .BANK domain. This does NOT mean that bank employees will receive fewer phishing messages from other domains. While the email authentication requirements dictated for a .BANK domain are good, there is nothing that stops your bank from implementing these today on your existing domain.
- Third-Party Providers: The final requirement of a .BANK domain is that any vendors that you allow to use the domain also comply with the DNS and Encryption requirements listed above. These requirements could easily be added to any vendor management program, regardless of which domain is used.
There is no harm in obtaining a .BANK domain if you have already implemented the controls required by the domain. If you have not implemented these controls, you should consider doing so…but most of the controls can be implemented regardless of which domain is used. The decision really comes down to whether you believe customers will trust .BANK more than a more common domain, and whether this trust is worth the marketing expense of switching domains.
We help financial institutions navigate tough decisions like this one and figure out what fits their needs best, but we're curious what tough decisions you've been facing lately in your institution? Email us your responses at support@bedelsecurity.com and who knows, you might just inspire our next blog post!