You don’t need a Chief Security Officer.

When hiring security leadership is a bad thing for a startup.

I helped many young technology startups last year (2016) build security programs from scratch, or at least start approaching the subject. Many of them ask if they should hire a CSO or a “security lead”.

My observations are that it can be harmful to introduce dedicated security employees too early at a startup. This introduction of a specialized role to solve a horizontal problem will often cause early fragmentation and organizational debts.

Instead, startups do better off getting short term guidance from external expertise and tasking existing engineering talent with security projects.

Here’s why:

Bad engineering teams will welcome reasons to ignore a debt.

Security is a form of technical debt. When asked to own security, engineering leadership will do one of two things:

1. Understand the problem. Prioritize solutions. Build.
2. Hire a Security Engineer or CSO. They’ll deal with it.

Security experts are useful in identifying risks and prioritizing mitigations. These skills are not needed to point out the earliest defenses at most companies. If brought on too early, this expertise is wasted when most early defense work is now very well known, even among non-experts.

The ability to work on a well specified security task in a timely manner should be expected of any software engineer. No exotic knowledge or skills are required to understand many of the various defenses an early startup could work on, especially in application security.

Additionally, no part of an engineering org should be exempt from working on defensive projects. Removing this early accountability towards security will deny your team culture from appreciating an entire area of debt they’ll face later on.

Warning sign: Do you have a single “security engineer” fixing security bugs created by the rest of an engineering org?

You wouldn’t hire a “Chief Scale Officer” when your engineers aren’t writing efficient code. Your problem would be: “shitty engineers”.

Engineers that assume a false sense of comfort that risks will be addressed up or downstream are lower quality than what should be demanded of them. Don’t create a culture that “the security team” will babysit those pesky security problems for everyone else. If specific risks are handled in code abstractions and frameworks, those benefiting should at least be aware of their existence as much as possible.

Developers ate operations, now they’re hungry for security.

Larger swaths of risk are quickly being eliminated at newer companies, at earlier and earlier stages. And usually not because security was the goal.

Some examples:

• Many startups aspire to being ephemeral, immutable, or entirely server-less. Attacker persistence is much tougher when environments are continuously rebuilt.
• An “Infrastructure as Code” driven culture would mean unauthorized changes outside of a git commit could easily have alarms and logging associated with it. Intrusion Detection in this sort of environment has amazing potential.
• Centralized logging is a fantastic tool for troubleshooting applications and infrastructure logs, and usually exists before security is even considered a goal. New companies have an easier time managing log infrastructure in the cloud or within their IaaS’s offerings.

As a result, common accepted security practices are being adopted because they’re just good practices altogether, and infrastructure platforms are baking security in at a faster rate than ever. Ask yourself, have you met a firewall engineer, lately?

The future is looking good. The practice of defensive security is becoming less specialized and building allies in SRE and DevOps.

The result is that it makes less sense to punt security to a dedicated individual, or leader, as early on than has historically been the case.

Get a security adviser.

Prioritization is a short term task that creates a longer technical road map. The working building on that road map should involve your existing engineers. You can easily get short term help to build that road map and be available for any one-off calibrations.

Your startup should find a local security firm, or bring an expert into a adviser role. Ask them to perform a risk assessment with your engineering or IT leadership. Task them in building a security road map with you, and help prioritize it to mitigate your biggest risks. Ask them to help calibrate or steer your engineer’s efforts over time, and have them suggest ways to check your engineering organization’s work.

What you do not want is to just be sold on security assessment-type work. You don’t want to be caught in an endless loop of vulnerability finding and fixing. What you are looking for are discussions on the best practices to build on that make sense for your specific risks.

This will help you avoid the costs of a full time security hire. These roles won’t contribute to your short term product goals when the company is thinking in runway time frame.

But… why do companies hire a CSO?

Despite my pessimism on early security leadership, specialized security teams always have a place at more mature companies. You will need to hire a CSO at some point.

A CSO, or any form of leadership in security, is expected to organize wide risks and security efforts into a story that earns the trust of others in your business. They’ll manage your ever changing debt across a deeply fragmented organization. They perform specific tasks to surface and mitigate unknown risks across more complex organizations. In many places, they’ll also organize your work into a compliance project for SOC2 or other frameworks.

The concept of risk becomes multi-dimensional depending on who is asking about it. The CSO role should know how to answer.

Most of their work will be hard to replace with technology. They need to handle highly specific subject areas that may never be completely disrupted by frameworks or infrastructure platforms, like any internal investigations, forensics, and vendor risk.

I should also add that dedicated security engineering teams become necessary at larger companies as well. When complex and sensitive code bases, abuse systems, or cryptographic dependencies are formed… it is impossible to avoid building organization to maintain them.

Be thoughtful of how much of the CSO role is necessary, and ask if it will really eliminate technical debt. Technical debt is the main reason you’ll be breached, not a title you haven’t filled yet.

Conclusion

Security work is well cut out for the first couple years at most organizations. If you’re falling behind, it’s not for lack of new leadership.

If you’re collecting security debt, don’t hire people to make it go away. You will not find relief that way when solutions are becoming more increasingly available for a DIY approach.

Continue building a powerful engineering organization and expect the first several years of security projects to come out of it.

@magoo

I’m a security guy, former Facebook, Coinbase, and currently an advisor and consultant for a handful of startups. Incident Response and security team building is generally my thing, but I’m mostly all over the place.