Having served as vCISO for dozens of organizations of every size and across many verticals for well over two decades, I occasionally (often) find myself in the position of capturing and explaining a company’s existing security posture to them. For this to be effective – to use this narrow, early window of opportunity as a trust building exercise and foundation for greater collaboration across multiple stakeholders (who might not trust each other) – many factors must be considered. If you’ve been following my writings over the years, you know the most important one, and it has nothing to do with “technology gaps” or “security findings”. Rather, it has to do with one overriding factor:
Storytelling.
If you can assess an organization quickly – meaning its business drivers, culture, anxieties (especially!), and moment in time (aka phase of its business cycle) – then the security pieces fall into place. As a side note, this confirms (to me) the argument that security is a business support function, never a business driver. To get there, you don’t have to perform extensive discovery: figure out these key factors, and you’ll be able to predict with a high degree of accuracy where the company lives in terms of process and controls. If you are given the courtesy of enough time to chat up the real insiders to get their opinions and reflections, that’s a nice bonus; your picture will get clearer. As a side note, this doesn’t take long.
Seriously, a few conversations is all it takes.
You can then mirror to the organization the story of themselves, and if you do it well, then you will have gained significant trust and can then delve into the details much more comfortably.
Just talk to people.
Anyway, over the years I have experienced the emergence of some guidelines that I find helpful to me, and today I wish to share one of them with you, mostly because I found myself explaining it in three different organizations in the past three months and the explicit explanation seemed to help gain even more trust.
I call it the “Four Buckets theory”, and it fundamentally applies to tech companies that live in the cloud, but it can be applied to many other for-profit enterprises as well, at least all those that heavily rely on technology. Its main purpose is simply to achieve greater, faster positioning alignment between what a company does and where I would expect them to be in terms of their security maturity, which can be very useful in the role of new CISO.
It really helps construct the story.
Critically, it steers away from failed approaches such as the “vertical expectations” rule of thumb: the idea that if a company is in a particular vertical, it will look the same as any other company that plays in that same vertical. People often do that; if you’re doing something in healthcare, then you must have considered HIPAA, or if you’re in retail, you must have created a PCI compliant environment. The problem is that these expectations, like so many do, often shatter against the shores of reality.
In these instances, the operative phase of disbelief is captured in the common phrase “wait, you’re doing THIS but you haven’t done THAT?!” accompanied by an audible gasp, often heard as part of the fabled discovery process.
The problem with this rule of thumb is that it fails to consider trivial elements like maturity of the company, the specific context of its product and what it does, or how far along it is as a business, and completely ignores human factors. It’s a very crude tool, and while it works (to a degree) often enough that people rely on it, it’s not, well, reliable. So let me share my little storytelling theory with you. Whether you like it or not, I hope it sparks some inspiration, and I state upfront that it is entirely empirical. I have no proof.
Just lots of experience.
As I discuss the buckets, you will observe that by answering a single question about a company, we can instantly derive a valuable set of expectations that will tend to be far more accurate about where the company security environment might be than with any other method.
The question is: “What are the common pressures that will naturally drive the emergence of a security program for companies in this bucket?”
We will, therefore, include “The Answer” in each bucket.
Ready? It goes like this.
All cloud tech companies fall into one of four buckets:
Bucket 1: b2b
Easy to understand. These are the multitude of companies that primarily sell some sort of cloud software product to other companies. SaaS, PaaS, and all that jazz.
The Answer: bucket 1 companies initially have little need for a security program, but as soon as they attempt to sell into the enterprise space (beyond initital proof-of-concept), they will run into a common set of security validation demands, because their enterprise buyers will force them to provide proof of their security posture (all those gorgeous security questionnaires).
Ultimately, their posture tends to consolidate around the easiest way to provide this sort of validation. By and large, bucket 1 companies have either considered or have already started pursuing the path of adopting a common provable standard (SOC2 is, at this time, the leading one) in order to support and enable sales. And this, in turn, will dictate their Security Operations focused control set.
All you need to figure out is where they are in terms of their market penetration, and a pretty decent picture of their existing security efforts will come into view.
Operating in a particular, regulated vertical, may indeed shift the goal posts, perhaps towards a standard that the vertical requires; so a healthcare business associate may be inclined to adopt, say, HiTrust – eventually. But even in these verticals, bucket 1 companies usually start with the most common ones like SOC2 and ISO27001, and build further on them afterwards.
Bucket 2: b2c
Also easy to understand. These are the smaller multitude of companies that serve consumers directly. Think social networks (e.g Facebook), consumer-facing marketplaces (e.g Stubhub), and so on.
The Answer: bucket 2 companies do not typically have a security standard as a driver, because nobody is forcing them to adopt one. Instead, their hands are forced early on by privacy rules, such as GDPR and CCPA. Their security programs reflect that, and they tend to have greater maturity around tracking and protecting PII, and less of everything else.
A key point is that, even if bucket 2 companies sell to consumers, PCI is often not a driver! It used to be, but these days it’s so easy to not handle credit cards directly, and instead have a company like Square do it for you, that it has become the default choice. Don’t fall into the trap of making this assumption just because they take credit card payments.
Bucket 3: b2b2c
A more interesting, significantly smaller, bucket. These companies are the ones that sell a product to other companies who, in turn, are themselves big b2c players, and that product interacts heavily with their consumer data. Behavioral analytics companies (e.g Amplitude) and ETL providers (e.g Mulesoft, Fivetran) naturally fall into this bucket.
The Answer: these companies face both b2b and b2c pressures, and so their security posture tends to mature faster; usually, when they make their upmarket move they end up facing both security and privacy requirements (and those gorgeous questionnaires), and must supply reasonable answers to both.
If their target vertical is also a regulated one, you can expect a surprising level of maturity much earlier than most any other cloud vendor out there. They don’t have a choice; for these companies, their very ability to survive depends on being able to relatively easily prove they are doing the right thing.
From a security perspective, they will naturally mature more quickly, will exhibit a program that combines the elements of both b2b and b2c companies, and do so earlier in their cycle. For them, it’s a matter of business survival.
Bucket 4: the rest
Ah. The smallest, and to me, most intriguing bucket. It’s also the trigger to why I felt inspired to write this article, because in explaining the concept, this is where it appears to elicit the greatest interest.
These are tech companies that, because of their niche and business model, simply do not face security or privacy related pressures (and scrutiny) until much later in their business cycle. They are, by their very nature, not easy to categorize like the ones that fall in the other buckets, but they do share some commonalities.
Before I discuss them, let me proceed to…
The Answer: because these companies do not face external security or privacy pressures, they tend to have security programs that are dependent on the specific knowledge and experience of their individual team members. This in turn leads to a security control environment that is both ad-hoc and localized.
What does this mean?
Ad-hoc means what we all know it does: shiny objects. Chasing squirrels. Something happens along the way that attracts attention internally, so someone decides to do something about it. It’s harder to predict which controls will emerge over time in this environment, but some certainly will, simply due to the nature of operating any sort of technology platform in this day and age.
Localized means that emergent controls will tend to be specific to where they emerged, rather than considered in the context of a larger ecosystem. Whatever triggered one of these controls will usually be conceptually constrained to where it happened, and the implementation of the control will likely reflect this reality. And whatever solutions get adopted will depend on what the team member(s) responsible for fixing it bring over from their previous job history.
It can all feel pretty chaotic, but one factor that makes these companies endlessly fascinating is that, while they tend to have inconsistent maturity and areas where, upon observation, you would shake your head sadly, their control environment often has areas where they are much more mature than they would otherwise be in companies falling into the other buckets.
For example, think of marketplaces that connects businesses rather than consumers, and whose primary customers are very small (single owner or few owners) businesses. In this kind of ecosystem, if it’s in retail, you might discover powerful fraud controls and an envious level of insight into social engineering that is ages ahead of much larger companies. If it’s in manufacturing, they will necessarily have developed remarkable capabilities around protecting IP (product or marketing designs) as it goes through their systems. If it’s selling solutions to marketing teams, timed content protection controls for what would otherwise require no thought at all – marketing information is, by its very nature, public, except during the time window before it gets released – can be downright incredible in the realm of data classification and handling.
These kinds of companies might not do very well in vulnerability management, but where it matters to them, they will blow your socks off.
None of this is unexpected, and this Four Buckets Theory is no way earth-shattering. But as a guideline to rapidly develop a fairly accurate set of expectations about a company’s security (and privacy) posture, it’s a useful tool that has served me very well for a long time. I hope you can find it useful as well.
–Barak
