The early and scaling years at a company are some of the most important in forming the company’s long-term attitude towards security. At a fast growing startup, there’s always more things to do than people to do them, and figuring out what the right amount of investment in security can be vexing for early employees and founders. We’re here to help you navigate those waters whether you are a security minded SRE, a founder, or the first security hire.

“Keep the company secure” is such an ambiguous goal. Decisions about how to accomplish that become impossible when considering the endless options of security controls and products that all seem to promise that. There’s no better visual metaphor for this problem than the RSA Expo floor, where vendors fight for the attention of buyers with expensive booths and flashy demos.

As if the challenge wasn’t already enough, the stakes are high. Fines and government intervention due to security breaches (and privacy violations, which are different but related) are not uncommon. What you really need in these early days is an outline of a todo list that will help you hang on until your company can scale to having a dedicated security organization.

Guiding Principles

Before getting into specifics, if you’re trying to make a difference and influence the security of an organization it comes down to three key things.

Relationships

Maintaining good relationships with your stakeholders is critical. Making security improvements has more to do with influencing the way other people do their jobs than the actions of any single individual. Without good relationships you won’t advance security too far alone, so focus first on being someone that other people would want to work with.

Shipping

A lot of security efforts have good intentions but fail because they are too big or attempting to boil the ocean. Sometimes big projects are unavoidable, but early on I can’t think of many multi-month single projects you should take on (except for compliance certifications that have specific time windows and schedules). Your security initiatives should have the same rapid shipping ethos that product work has, and maintaining that for as long as possible is a good thing. Projects that are too big or focus too much on major non-pragmatic changes also won't resonate with your peers and can harm relationships

Focus on the fundamentals

Fancy security research and development makes a great DEFCON talk but it is rarely the most important first few work items that will improve a company’s security posture. It might be in some newer tech industries like cryptocurrency or AI, or with experimental technology. Those best practices will need to be done eventually so focusing on doing the basics well is time well-spent when small.

Establish a culture of security

With an infinite budget there are some aspects of a security program that your company can’t buy. Having a strong culture around security has a direct impact  on the bottom line for your business and your customers.

The good part of this is it completely free, doesn't require complex tools, or even require a large time commitment. On the flip side, improving a bad security culture can take years or be impossible to change once a bad culture has metastasized.

Hopefully these few intentional steps will help you establish a strong security culture early on so it doesn’t become a problem down the road.

Establish a safe place to report security issues

When things go wrong, and they always do, your teammates and security researchers outside of your company need a channel to tell you about it. In previous roles, I’ve seen this take the form of an email alias where employees of the company are trained that they can email that alias to get help with security issues or anything else that comes up and is urgent.

It is more or less a hotline or bat-signal to get security help or a second pair of eyes on a problem. I recommend keeping the internal and external alias separate. Give the internal one a descriptive name or make it an acronym like “sirt@” (security incident response team) or “security-incident@” or anything memorable that you like. The external alias should be “security@”.

It’s important to ensure that people who use the alias don’t feel punished if they are wrong about what they report, and you’re prepared to be interrupted by issues that someone believes is urgent but might be wrong. If someone noticed something they thought was out of place, and had good intentions, reporting something and having it be a false positive is the best possible outcome.

Be prepared. These aliases over time get used for things that aren’t the technical security issues you expected. For example, employees dealing with harassment over social media, cyber-stalking, etc will likely use this alias and that means it’s working as intended because your security program is trusted. It’s important that the people experiencing those problems have a safe avenue to get help even if it isn’t quite what you expected when you wanted to “Keep the company secure”.

“Security is everyone’s job”

Intentionally messaging that security is a part of everyone’s job goes a long way, especially coming from company executives. That mantra needs to be actionable though. Make sure you are giving clear directions about how teammates can help.

There are a few actions you can encourage others to do:

1. Report security issues or security mistakes to the security email alias.
2. Urgently fix security vulnerabilities via patching or product work when those issues come up.
3. Before sharing sensitive company data with third parties or using new vendors, ask if it's okay first, or if we should share that kind of data.

There’s no end to little ways that members of your organization can be more conscious about security, and you likely won't know how to handle every situation that comes up, but it's the thought that counts. By making it relatable and actionable, you have the best chance to influence their behavior.

Celebrate security wins

Celebrating victories and little wins is part of the startup ethos. Security wins are no different but they often go overlooked. Make sure you regularly celebrate security wins, and celebrate everyone involved no matter how small their role was.

Making your messaging centered around your customers goes a long way to connect security to your bottom line and engrain it into your culture. “We fixed X bug, and now our customer’s data is safer!” is a great example of this practice.

If you want to watch a fantastic talk that epitomizes establishing a great security culture in practice, this talk by Eric Ellett is a fun story (from a few years back but timeless).

Best Practices are your first security projects

A few years back I gave a talk at AppSec California. There’s a wealth of information in that talk and I sometimes get nice messages from people who watched it and found it helpful. I want to give some of the same advice but abridged and slightly more specific.

One of the coolest things at a startup is that any one person can accomplish a lot and change the trajectory of the business quickly. That’s a huge opportunity in security because most problems get more complicated and hairy as the company gets larger.

There are a few things that are really important you prioritize when you’re small, otherwise they will become a nightmare later-on.

Identity and Access Management

You’ll never be “finished” with identity and access management, access control, and similar. There’s no silver bullet or one size fits all solution either. There are a few things you should do early on though.

Two-factor authentication everywhere, preferably FIDO2 or Webauthn

FIDO2 / Webauthn is the most effective way at preventing phishing. There’s no amount of training or fast responses that can overcome how easy it is for even experienced security professionals to fall victim to phishing. Phishers only need one person in your company to fall victim to it. You might think “We’re too early to worry about this”, but if you wait until it’s an actual problem, it becomes a lot more problematic switching to a phishing resistant second factor once a few years pass.

API Keys and Secrets Management

Mis-managing API keys, especially AWS credentials, is the most common way that companies have their tech stacks compromised. Your team needs somewhere to keep secrets for their services to use, and a mature enough dev environment that it doesn’t rely on production secrets.

As a rule of thumb, encourage a hard stance of no production secrets and keys used on developer laptops for development or day to day operations. Once your company gets past a certain size it’s inevitable that, with bad practices, someone will eventually post an API key to an npm package, git history, or somewhere else they shouldn’t be.

Incident Response Plan

Your team is only as strong as they are on their worst day. Incidents and security problems can be stressful to deal with and even the most grizzled security veterans can lose their cool. We all deal with stress differently and having a documented security incident response plan, even if it’s basic, can be a huge help in managing your team’s stress level during those bad days.

There are a few basic questions that your incident response plan should cover.

1. At what point will you escalate externally? You might need to call in backup if you don't know what to do. You should figure to whom you will escalate. A trusted advisor, investor, or outside third party are all good people to keep in mind.
2. How will the incident response process work? Most software companies have on-call and incident management processes already. It’s okay to borrow or even wholly use this process. If the issue looks like it will be long-running, set up a group chat for off-hours communication.
3. How will you communicate the issue internally and externally? If you have a comms or PR person it is a real asset during these situations. When disclosing to your customers you’ll want to be as transparent and actionable as possible. When communicating within your company, give the customer facing teams the information they’ll need to interface with their customers.
4. Are there reporting obligations? This is a legal question. You should be asking your outside counsel if you have any questions about this whatsoever.

Compliance and your security story

With companies like Vanta, Drata, and SecureFrame making SOC2 easier, companies are getting SOC2 earlier than ever before. Compliance for the sake of compliance is fine early on, but being able to also talk about your key practices and security controls makes a big difference in strengthening the way your customers and potential customers view your security practices.

You should have a list of three or four security practices that you’re really proud of and will make customers feel better. Some ideas about what these could be:

• Strong second factor authentication everywhere.
• Good practices within your cloud environment.
• Secrets management practices.
• Centralized collection of security data with RunReveal =]

One thing to note. When you're talking to customers, don't lie to them or try too hard to paint your security practices in a positive light. If some of your security practices could be improved it's okay to share that and it's likely your customers find that more relatable anyways.

Security Reviews

When releasing new products and features, improving existing ones, it’s incredibly important to establish a lightweight SDLC and security review process.

Without a dedicated security team, it’s likely nobody will have the experience to do secure code review or security audits. Until you have that kind of expertise, there’s a few simple things you can do to make your software better, get in the practice of lightweight process, and not need special security expertise.

• Document project plans and software architecture.
• Will this allow one customer to see or make requests and retrieve other customer’s data?
• Are there any secrets directly in the code that shouldn’t be?
• Does anything in the OWASP Top 10 jump out as something that might be problematic? You may want to dig in a bit deeper if so.

It’s likely that when your company is small, these types of questions will be tough to unpack. Spending a few minutes thinking about whether or not certain attack scenarios might apply to you is a way to ease into threat modeling and heavyweight pentesting in the future.

On-boarding and Off-boarding

If your company is doing a lot of hiring, this will save a lot of time and in addition to making your company more secure. These processes can become pretty automated over time with endpoint management tools and single-sign on doing much of the heavy lifting. If you’re not willing to make the investment in SSO or endpoint management tools early on then making sure you have a really complete checklist for on-boarding and off-boarding will pay massive dividends over time.

What’s important is that:

• Endpoints are configured to have full disk encryption and automatic updates enabled.
• Employees lose access to your company assets after they leave the company.
• You can accomplish these two things without mistakes and quickly.

Takeaways

Security matters a lot at a startup. It doesn't need to be slow, expensive, or really confusing. I hope this is helpful and approachable to people in all kinds of roles at tech startups.

If your goal is to keep the company secure, there are only a few common ways that most companies get compromised and it's important you prioritize security controls preventing those scenarios, while building a healthy long-term security culture.

You can definitely accomplish that if you build positive relationships and a positive mindset around security, while focusing on rapid improvement and iteration in those few areas that matter. You got this!