We all know and love—or at least begrudgingly rely upon—email. It is a pillar of modern communications, but is unfortunately also highly susceptible to being leveraged as a mechanism for malicious actions, such as spoofing or phishing.

A core concern regarding email is the authenticity of the source, and in recent years, DMARC has arisen as the preeminent email validation system. DMARC builds upon the foundations of two older email authentication systems, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM), which respectively check for mail server authorization (“Is the sender authorized?”) and email integrity based on key signatures (“Was the content altered?”). The various components of DMARC can serve to mitigate direct threats as well as potential reputational damage, such as spoofed emails intended to mislead partners, suppliers, or customers.

A properly implemented DMARC system can identify illegitimate emails and define how those emails should be handled. DMARC can be configured to handle emails of suspect provenance with different degrees of severity, depending on the aggressiveness of IT administrators. The DMARC policy options include:

• None, where suspect emails are reported to a designated email address that serves to monitor DMARC notifications.
• Quarantine, where suspect emails are punted to the spam folder and a report of its receipt is delivered to the monitoring email address.
• Reject, where in addition to notifying the monitoring email address, suspect emails are not delivered at all.

By virtue of its efficacy in mitigating malicious messaging via email, we consider DMARC a significant risk mitigator and highly recommend its implementation. Unfortunately, while the benefits of DMARC are profound, its implementation is not global.

DMARC's implementations are tracked in public Domain Name System (DNS) records. To determine whether an organization utilizes DMARC only requires the examination of the organization’s published DMARC record. We are able to discern the scale and types of DMARC implementations by comparing the primary, well-known domains of the Fortune 500 organizations against their corresponding DMARC records that appear alongside DNS.

These published DMARC records are intended to be highly accessible. They are the means through which email recipients determine how to validate emails using DMARC, what email address to notify when receiving emails that fail DMARC validation, and what DMARC policy to apply in handling invalid emails.

We find that in absolute terms, there are clear variations in terms of DMARC saturation for the different industries represented in the Fortune 500. When we examine the financials industry, for example, we find that many organizations are quite aggressive with their DMARC implementation with a reject policy in place, with a nearly equal number of organizations configured to simply monitor.  The high degree to which DMARC is present for the financials sector is unsurprising, given that financial organizations were some of the earliest adopters of DMARC.

Somewhat disheartening is the lack of any DMARC implementations across all other industries to some extent. For opportunistic attackers who might leverage email as a means of exploitation, no industry is categorically off-limits.

It is worth noting that while the state of DMARC across the Fortune 500 is not perfect, there has been respectable progress. From 2019 to 2020, the number of organizations within the Fortune 500 that had no valid DMARC implementations declined from 186 down to 121—a difference of 65 organizations. The increased adoption of DMARC in that period corresponded with an increase of 51 DMARC records set to reject (a 75% increase), as well as an increase of 15 records set to quarantine (a 55% increase).

The number of domains that persisted from year to year with a DMARC policy of none (i.e., report only, but take no action) remained fairly constant. This implies that there were a sizable number of organizations that adopted a set-it-and-forget-it attitude—they probably implemented a minimum standard of DMARC at some point because it was recommended, but have since either forgotten about it or have chosen not to improve on it, neither of which are ideal.

Nonetheless, in 2020, the Fortune 500 in aggregate became notably more hardened to illegitimate emails.

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 that are 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.

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).

If you haven’t thought about your site’s encryption for a while, now might be the time to revisit it.  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 re-evaluating your entire application security program.

Back in 2018, when we began our first foray into analyzing the cyber-exposure of the Fortune 500, we created the term “version dispersion” to refer to the diversity of versions within a service component an individual organization was exposing to the internet. With the dramatic rise⁴ in enterprise use of tooling such as Kubernetes,⁵ we expected to see a reduction in version dispersion of the three web servers—IIS, Apache, and nginx—that we previously measured.

There are at least over 81 distinct versions of Nginx⁶, 70 distinct versions of Apache, and 15—yes, 15—distinct versions of IIS⁷ running across Fortune 500 members. Let’s see how that stacks up per industry.

A higher density of points toward “1” on the X-axis means that each of the organizations those points represent are running with a low version dispersion. This means they have better control over server/service deployments and configurations, have fewer versions to test patches against, and can make changes faster and with more confidence than others. It also likely means they have a more rigorous “you must be this tall to deploy a server on the internet” rules than organizations that are further to the right on the X-axis. Attackers and cyber-insurance assessors alike notice such things and may be more likely to target organizations that exhibit a more “wild, wild west” stature.

For this chapter, we’ll be talking to two different sets of CISOs: those who see their image reflected in the mirrors in each of the sections, and those who have organizations like this as business partners or suppliers.

If you’re a security leader who is working to build resilience and safety into the DNA of your organization, issues such as technology sprawl, version management, and critical service maintenance are non-negotiable must-haves. The good news is that these aren’t just “security” issues. Organizations deploy services to meet a business need, and it is far easier to sustain service uptime and stability if there are fewer moving parts to maintain. To achieve buy-in with your peers, collect historical and current data regarding service degradation (and/or outages). Add to that data how long it takes IT, application, and operations teams to support each component of each business process. If you pair that up with information on the volume and severity of identified weaknesses (CVE-based or otherwise), you will find areas that have a solid business case to warrant partnering for improvement. As each area ameliorates, you’ll have far more agency to affect change in other, lagging areas.

For those who shuddered at what this section revealed, make sure these are areas you look for when evaluating third parties on behalf of business process stakeholders in your organization. It’s fairly straightforward to both ensure you’re asking about these potential areas of weakness and verifying¹⁴ that the answers you receive are accurate. There’s no guarantee that the internal exposure of organizations reflects what is seen externally. However, it is generally more likely that the internal picture is even worse than what is presented to the outside world. Holding your partners and suppliers to a higher level of safety and resilience will not only lessen the risk to your organization, but can also have a cascading positive effect as other organizations follow the standards you’re setting.

The findings here indicate that even some of the most resourced companies are exposing services that have an outsized risk. 

Our guidance for addressing the risks above isn’t to implement some advanced security controls or software, but to instead return to the basics. You can find all of them in the early parts of the CIS Top 20 ²⁷ controls.

• Develop and maintain an inventory of internet-facing hosts that includes software versions, roles, and services that are expected to be exposed, as well as the reason why. Make sure that this inventory is validated by outside-in scans of all of your public-facing IP ranges.
• Implement security policies and supporting configuration standards that enforce the use of secure protocols and configuration settings. Using the example of Telnet, every device currently using Telnet should be able to support SSH—and if it doesn’t, it is too old or insecure to be directly connected to the internet.
• Ensure that software and hardware are kept current. In many cases, such as with Microsoft Windows, newer software brings better security features and controls. Older software’s lack of these features can force security trade-offs and require the implementation of compensating controls, which add complexity.

In January 2019, Casey Ellis, founder of Bugcrowd, remarked in a blog post that "only 9% of the Fortune 500 run vulnerability disclosure programs.” ³⁴ Therefore, the most surprising finding in this 2021 survey is that nearly 20% of the Fortune 500 signal a VDP. We were able to discover 99 vulnerability disclosure programs across the 500 companies investigated in January 2021. Even more heartening is that among the top 100 companies, a whopping 46 have a documented, easily discoverable mechanism for reporting product or infrastructure vulnerabilities.

With that bit of good news out of the way, however, we must look at how the rest of the Fortune 500 fares. Figure 18 breaks the surveyed companies down into quintiles based on their reported revenues for 2020:

There is a marked drop-off in the presence of a VDP per quintile, except for the last quintile, where there's a marked increase again matching the third quintile. This rise in the first quintile may be partially explained by the fact that there are twice as many Technology sector companies in the bottom 100 as there are in the second quintile, and five out of 10 of those companies do have a VDP. In fact, as we'll see in the next section, Technology is the only sector in the Fortune 500 where the majority of companies have a VDP.

Figure 19 breaks down the Fortune 500 by industry, and demonstrates that, as one might expect, few industries outside of the technology sector have normalized and internalized vulnerability disclosure as a component of their businesses.

While the technology sector is unsurprisingly at the top of the list, the astute reader will note that this figure is sorted by percentage of companies within that industry that have a VDP, rather than by raw count. This is because the Fortune 500 is dominated by the financial sector—after all, that's where the money is (to borrow Sutton's Law), and it's no surprise that nearly one-fifth of the top-revenue companies in the United States are primarily engaged in financial services. So, while 21 financial services companies have a VDP, that is only 23% of all financials represented by the Fortune 500, which is nearly the same percentage as those found in the business services sector and somewhat less than the auto industry.

The key takeaway from this view of the Fortune 500 is that, while all major companies have some technical component (and therefore have technical vulnerabilities), nearly 80% of these top companies in the U.S. outside of the technology sector lack a formal vulnerability disclosure program. While this might be understandable in prior decades, this state of affairs is simply unacceptable in today's hyper-technical business environment.

The lack of VDPs across the upper echelons of American economy discourages the reasonable and responsible disclosure of newly discovered vulnerabilities in their products, services, and infrastructure—after all, VDPs aren't just for reporting software bugs in software applications, but are also useful for reporting the discovery of sensitive data found about customers or company internals left open on insecure cloud storage. It is, of course, possible to disclose vulnerabilities to companies in industries without a formal VDP, but the lack of VDPs introduces inefficiencies for the companies and legal risk to researchers.

Finally, a functioning VDP signals that a given company has made some investment in their overall information security program, so it stands to reason that the lack of a VDP is signaling the opposite. Every company on this list has a website privacy policy, so every company should have some formal method for receiving and handling vulnerability reports.

Throughout this report, we've kept our focus on what CISOs in the Fortune 500 can do, today, to reduce their exposure to the most common issues we've discussed here. For the reader's convenience, those recommendations are summarized here.

Email Security: If you're on the Domain-based Message Authentication, Reporting & Conformance (DMARC) path, like 75% of the Fortune 500, that's great! Now is the time to plan out how you'll move from a p=none to a p=quarantine policy, and ultimately a p=reject policy. This is not an easy journey, since you will certainly uncover pockets of shadow IT running their own email infrastructure, but the confidence of being able to authenticate mail from your major brand domains is a pretty great feeling, and a nice item to report to your board of directors.

Web Security: HTTP Strict Transport Security (HSTS) is rapidly becoming table stakes for running a reasonably secure website, and this is the kind of security feature that browser manufacturers like Google, Apple, Microsoft, and Mozilla are likely to enforce in future versions of Chrome, Safari, Edge, and Firefox. It's a relatively easy switch that CISOs can flick (compared to the universe of nice-to-haves in cybersecurity, anyway), so take some time to investigate whether your organization is using HSTS and if not, why.

Version Dispersion: For the mega-corporations that roam the fields of capitalism, mergers and acquisitions are a fairly common activity throughout the year. That means the Fortune 500 CISO is never truly "done" with ensuring version consistency across the enterprise, even after investing in an excellent asset and vulnerability management toolchain. New networks and network services will join your ranks, and that means undertaking a fairly continuous modernization and normalization effort for those new assets. Taking on this continuous effort will pay off in easier, more straightforward planning for the next patch cycle, scheduled or surprise.

High-Risk Services: Telnet, SMB, and RDP have no business being exposed directly to the world at large, and are just waiting for the next self-replicating cyberattack to sweep across the internet. An up-to-date inventory of exposed services, sourced from internal and external scanning, is worth its virtual weight in Bitcoin, and will help you enforce a no-nonsense policy of network service exposure to the internet.

Vulnerability Disclosure Programs: As a CISO, you might have hired on the best of the best software, QA, and platform engineers. But, without a good way to harness the smarts of the tens of thousands of talented hackers around the world, you may never learn about the most critical vulnerabilities in your products and services. A VDP is a bridge to that enormous community of well-meaning investigators who have goals aligned with your own: a safer and more secure internet. Getting that program spun up now will give you plenty of time to practice safer software production. As a bonus, most of the pioneering work is already done for you, in the form of ISO 29147 and ISO 30111.