This blog post covers key takeaways from our 2021 Industry Cyber-Exposure Report (ICER): Fortune 500. Original analysis for these findings was conducted by Curt Barnard.
The vast majority of the interactions an average person has with technology is through some form of a web application, but what constitutes a “web app” can be considered quite nebulous, and the security controls for hardening these applications are equally broad. APIs, distributed authentication schemes, single-page applications, and static websites all might fall under the general category of “web application.” There are very few security measures that should be applied to all web applications across the board without further subdividing what specific type of application we are referring to. However, there are a couple that we will examine here.
All web applications should require strong encryption, with a vanishingly small number of exceptions. While this is most critical for applications serving up critical or sensitive information–such as personally identifiable information (PII)–it is important even if you serve only static informational content. There is a common misconception that the risk of using an insecure connection is a loss of confidentiality; that the information a user is browsing could be observed by a malicious third party. While this certainly is a risk, it is often overlooked that a lack of encryption makes the connection vulnerable to modification (a loss of integrity). This means that malicious third parties could not only observe potentially confidential information, but that they could alter that information or inject their own content that could potentially compromise your users.
The risk of malicious content injection exists regardless of whether your web application serves sensitive information or just cute pictures of cats. Due to this universal risk to a site’s users and to the overarching brand reputation of the site owner, we will consider the support of strong encryption (in our case, TLS) and the enforcement of its usage via HTTP Strict Transport Security (HSTS). For the purposes of this section, we will look at the primary domain for each company, as it is the domain that is most responsible for a company’s brand reputation.
HTTPS is the protocol that ensures web traffic is encrypted and secure. There are a few ways that HTTPS can be configured in an environment:
- Not available (HTTP only)
- Available and optional
- Required (HTTP "Strict Transport Security" or HSTS, configured)
- Required with HSTS preloading
Supporting HTTPS for your site is table stakes for having a web presence at all, with requiring encryption following very closely behind. HSTS preloading does carry some technological challenges, but they are challenges that a web security program should be working to proactively address.
With all this said, let's share some good news right off the bat: Among the sites we examined in the Fortune 500, 100% of them supported HTTPS.
The outlook for HSTS adoption was not quite as impressive.
As you can see, just under half of the sites examined supported HSTS in some capacity. While this may seem decent at a cursory glance, if the site already fully supports HTTPS (and these sites all do), it should be relatively trivial to implement HSTS to guarantee your users visit the secure version of your site. Many of these sites do provide a redirect from the insecure version of their homepage. However, that will not mitigate a man-in-the-middle (MiTM) attack.
Of the sites that do support HSTS, three of those sites have actually configured it to be explicitly disabled (as of the study time of January 2021), meaning they had supported HSTS at one time, but no longer do. Hopefully this was a temporary measure to resolve an implementation issue.
Eighty-nine percent of sites that support HSTS also support the “includeSubDomains” directive, protecting the entire domain and all subdomains. This is a fantastic security feature that can be difficult to implement in certain situations.
Forty-seven of these sites support the “preload” directive. This directive will cause crawlers to automatically add your site to a global list of known sites that support HSTS. If a supporting browser is directed to a site with HSTS enabled, it will guarantee that the first connection is always conducted over HTTPS, meaning it eliminates the one, single place where your site’s users are vulnerable to MiTM attacks—the first connection to your site before an HSTS header has ever been encountered. This configuration option is a simple way to add an extra layer of protection for your users, and if you bother to enable HSTS, you should certainly add this option. While it’s a somewhat newer directive with less browser support, there is no downside to including it (browsers that do not support HSTS will simply ignore it).
Securing and encrypting traffic to your user-facing domains is not only good practice, but it also protects your corporate brand. Securing HTTP with TLS has been a major point of focus for the web-security community for the past several years, and for good reason. All of the Fortune 500 companies fortunately provided a secure version of their primary website, but they have a long way to go before they come up to snuff in terms of best practices. The lack of proliferation of HSTS across the F500 is a good indicator that their application security programs are falling behind, especially since other, more sophisticated, mitigations can be significantly more complicated to implement. While the standards certainly move quickly, it’s important to keep up to speed, especially when your brand reputation is on the line.
If you haven’t thought about your site’s encryption for a while, now might be the time to revisit. A company’s brand reputation is on the line when consumer-facing web applications suffer from security failures, and it’s important to consider this fact when making investment decisions in various security programs. If your company’s website is not supporting HSTS, it might be worthwhile to find out why. Is it a technical, organizational, or budgetary constraint? Finding the cause could be a great springboard for reevaluating your entire application-security program.
Want to learn more about the internet-facing cyber-exposure of the Fortune 500? Read our 2021 Industry Cyber-Exposure Report (ICER): Fortune 500.