Security and the One Percent: A Thought Exercise in Estimation and Consequences
Richard Bejtlich • October 31, 2020
security 1%
Introduction
A First Cut with FIRST
even if every single US FIRST member represented a publicly traded company
FIRST representation for US publicly traded companies is only 2.5%
Beyond FIRST
estimate that says 75% of publicly traded US companies have sub-par or non-existent security programs.
5.6 million employer firms in the United States in 2016.
This creates a total of 4,000 US organizations with decent security, out of 400,000 that need it. Those 4,000 are the security 1%.
40 US security teams that qualify as global leaders and innovators
These 40 are the US .01%.
that US group of 400 is the .1%.
Sanity Check: A Few Statistics
Accenture Security Third Annual State of Cyber Resilience Report
PWC Global Digital Trust Insights Report
DBIR
DBIR
Security and the One Percent
These are the 1%
If those are the 1%, it means that the 99% are not included in these discussions.
mean nothing, or almost nothing to those 99% of organizations that do not have security capabilities
An Analogy: Personal Finance
The Consequences of the Security One Percent
The consequence of the existence and mindshare dominance of the security 1% is that the strategies and tactics they employ may work for the 1%
, but not the 99%.
methods that the security 1% use to defend themselves are irrelevant at best to the 99%, and damaging at worst to the 99%.
They end up simply being victims when actual intruders use PESTs to pillage the 99%'s assets.
Conclusion
the benefits of certain activities that may accrue to the 1% may be, and likely are, irrelevant and/or damaging to the 99%.
I challenge the security 1% to first recognize their elite status, and second, to think how their beliefs and actions affect the 99% -- especially for the worse.

Recently, I had the privilege to write a detailed analysis of CVE-2023-34362, which is series of several vulnerabilities in the MOVEit file transfer application that lead to remote code execution. One of the several vulnerabilities involved an ISAPI module - specifically, the MoveITISAPI.dll ISAPI extension. One of the many vulnerabilities that comprised the MOVEit RCE was a header-injection issue, where the ISAPI application parsed headers differently than the .net application. This point is going to dig into how to analyze and reverse engineer an ISAPI-based service! This wasn’t the first time in the recent past I’d had to work on something written as an ISAPI module, and each time I feel like I have to start over and remember how it’s supposed to work. This time, I thought I’d combine my hastily-scrawled notes with some Googling, and try to write something that I (and others) can use in the future. As such, this will be a quick intro to ISAPI applications from the angle that matters to me - how to reverse engineer and debug them! I want to preface this with: I’m not a Windows developer, and I’ve never run an IIS server on purpose. That means that I am approaching this with brute-force ignorance! I don’t have a lot of background context nor do I know the correct terminology for a lot of this stuff. Instead, I’m going to treat these are typical DLLs from typical applications, and approach them as such.