Sub-Venture Scale Security Problems

Thank you to Kane for coming up with the main thesis and as primary author of this piece. Check out his blog for a lot more great security writing.

There’s been some recent discussion about the niche problems in cyber security we all seem to have. The venture capital model is focused on large addressable markets to get big wins, and these problems just don’t qualify for investment. This leads to security engineers fixing the same undifferentiated problems internally every time they join a new company because there is no “buy” alternative.

Many other domains have a healthy set of smaller tools on the market, often built by small companies, solopreneurs, and side hustlers. If you look at professions like marketing or sales, you’ll find a veritable ecosystem of SaaS apps, chrome extensions, excel connectors, and more. 

The world of micro SaaS is growing and today there is even an ecosystem of accelerators to get micro SaaS companies off the ground and acquirers to sell them to. Yet you’ll rarely find any security companies in this ecosystem and there’s a simple reason why – risk. 

The cards are often stacked against small cyber security companies:

• Security tooling is a high-risk domain

• The required security baseline requires investment upfront

• This causes slower and more onerous procurement processes

• Risk-averse buyers prefer to do things internally

• Lack of available funding to get small ventures over the initial hurdles

The cybersecurity market does have a number of vendors solving these smaller problems, but they tend to congregate into services businesses like Managed Security Service Providers (MSSPs), pentesting companies, and consultancies.

If we ignore those domains, there are a few companies that have managed to beat the odds and bootstrap into a niche for themselves on the market but they are few and far between. If you look at bootstrap successes you’ll commonly see companies like Thinkst Canary, PortSwigger or AssetNote mentioned.

These companies show a trend: bootstrapping is more viable when the product does not require sensitive data or can be segmented away. This allows founders to avoid many of the hurdles around risk aversion.

We wanted to give some examples of specific problems that we encounter time and time again. We end up either fixing these internally or just accepting the risk, all while wishing we didn’t have to. 

HRIS vendors like Workday, Rippling and Personio are the source of truth on employees for most companies. Other systems, critically Identity Providers like Okta, rely on the information they contain. HR is a complex area and often changes happen rapidly, with acquisitions, new countries, and changing org structures. These changes are generally done either manually, or through lossy processes like importing artisanally crafted CSVs.  

These changes are often made without consideration of the downstream impact on other systems, which can wreak havoc. We’ve seen multiple incidents in this area, from a change that accidentally removed everyone’s access to everything, to a change that accidentally gave all of engineering access to production systems.

Some places have tried to solve this internally, either:

• building a terraform layer on top of the HRIS system, which is often unwieldy and slows things down, or

• having some system to connect attributes across multiple systems, warning HR of the downstream impact they will cause, or

• building and relying on “dry-run” capabilities, and implementing emergency-brake rate limits

This problem (to our knowledge) does not have any narrow vendor solution yet because it deals with the most sensitive systems in the company and likely isn’t big enough that companies would pay significant amounts for it. Additionally, every vendor in the space will claim their product won’t suffer these issues.

EDR tools give you the ability to get vulnerability data from endpoints, and MDMs have the ability to update packages, but there’s often no easy way to tie these things together. Canva wrote a great example of what they’ve built internally to enrich datasets and give information, which is a great start, but going beyond that you’d also want to have automatic remediation policies.

Modern, “SOCLess” security operations programs generally rely on interaction with end users to enrich or confirm various alerts. This goes back a decade, to Square, Slack, and Dropbox. The SOAR tools in the automation space make this easier, but that still requires both investment in a SOAR platform, and significant implementation efforts. Many times we’ve seen security teams build out a communications bot either from scratch or via SOAR tools that they need to maintain, just for basic user interaction with alerts. The flexibility of SOAR tools is amazing, but often teams just want an easy-to-deploy bot they can connect in with all their security alerting infrastructure. 

Many large security organizations have detection engineering teams, which all too commonly build the same basic alerts. Detection engineering teams, like platform engineering teams, should spend their time working on problems unique to the organization. We need to stop building a “file was transferred to a USB stick” detection for the umpteenth time. There are a bunch of caveats, including vendor heterogeneity, but the majority of companies use the same few tools. 

There’s a bunch of open source sharing that goes on which helps alleviate some of this problem and a bunch of contracting companies who have an arsenal of pre-built detections, but there’s no reason this can’t be a click-to-deploy detection library. These detections could be across multiple areas including typical SIEM detections but also things like SAST. This is an example of a problem where there are definitely managed service providers who offer this, but there isn’t a plug-and-play product available otherwise. 

Companies working heavily in the cloud all end up requiring an additional layer of tooling on top of the cloud providers authentication flows. This paves a road with enterprise features like secure storage in the keystore, easy onboarding, homogeneous multi-cloud support, profile and session management, and numerous developer experience improvements. It also extends into other resources, allowing employees to easily access cloud resources, like servers and Kubernetes clusters. 

We find this example interesting because there have been attempts to commercialize open-source in this space, such as Noovolari (that recently shut down). It’s also available, as with User Notification, as a component of larger Cloud Access platforms. However, a narrow vendor offering focused on access ergonomics would have a place in many cloud security programs, if it weren’t for the limitations stacked against startups: this touches a companies “crown jewels,” and likely isn’t big enough that companies would pay significant amounts for it.

There’s no doubt about it that starting a small business in security is a difficult endeavor. The fact that cyber security salaries are high also means there’s not a great incentive for people to start risky endeavors that only have a small chance of increasing their income in the long run.

Procurement teams have stricter requirements every year, and filling out lengthy questionnaires is the norm in today’s environment. Add into this the risk-averse nature of security teams and you can see why there aren’t many small businesses in this domain.

This being said, it’s getting easier and easier to start a secure company. Cloud-native design has been a win for security, removing many of the footguns of the past and making secure-by-default the norm when spinning up new services. These days, it’s common to see startups launch with SOC 2 in hand, with just a few employees and a few months.

There’s a sort of funny irony that new businesses are probably more secure out of the gate than many legacy ones. You look at the big public breaches over the past few years and you’ll find that real-life attacks are usually basic phishing, credential theft, or compromise of legacy infrastructure. A small business with security keys, passwordless, Chromebooks and no legacy infra would be leagues ahead of the enterprises of yesterday in terms of security, they simply don’t have the required documentation and attestations to back it up.

Open source can undoubtedly help but isn’t a panacea. osquery is an excellent example of this.

Many people (including ourselves) have deployed osquery for endpoint visibility and found it very helpful, but managing and maintaining the fleet can be a beast. A whole industry, including companies like Fleet and Kolide, have spun out to make deploying and managing osquery easier.

Many security teams are small and can barely spare the resources to focus on a tool, let alone deploy and maintain on-prem software across multiple platforms. This assumes they even have the engineering skills to deploy it in the first place, which is another blocker to more widespread uptake.

So all of this being said, how can we reduce our issues and help small companies get started in cyber security? 

• Confront our biases about small companies. A startup today, if managed well, is ahead of many enterprises today. Yes there’s always a reliability risk that a small team may not be able to respond as fast or have dedicated security personnel, but real breaches happen due to people and legacy infrastructure, both of which can more easily be managed by a small team of people who know what they are doing.

• Move from compliance to proactive security. Rather than implementing minimum security baselines which create an unequal playing field, move to proactive partnerships, audits and testing. If we can kill dumb security questionnaires along the way, all the better. 

• As a company starting out, you need to focus on data security and segmentation. The less access you have and the more you can contain, the more likely it is that you’ll find willing customers.