The Startup's Guide to Building an InfoSec Program - Part 1

Inevitably, early-stage companies must decide when to take their InfoSec program from zero to one. RedSquall wrote this blog series to outline the steps for founders, executives, and leaders within a company to do so effectively and with minimal disruption to the velocity needed for startups to survive. 

Part 1 of this series focuses on identifying gaps, prioritizing them, and bringing the right people in to close them. Part 2 will focus on the execution phase, which includes building your security stack, selecting vendors, and avoiding money sinks in unnecessary tooling.

As early-stage companies come out of "stealth mode" and begin marketing their products, especially to enterprise customers, they quickly realize that no matter how good their product is and how bad the customer may want it, if their "security house" is not in order, deals are not going to close. Large enterprise customers have mature compliance requirements for vendors that are often very rigid and do not allow many exceptions. A customer's compliance team can slow a deal down to the point where customers seek out other vendors to fulfill their needs. If you find yourself in customer pre-sales calls fending off their infosec teams and dreading security questionnaires, now is the time to start leveling up your infosec program.

If multiple people own it, no one does

Like most things in a startup, responsibility for security-related work is shared. Sales calls focused on security will most likely have a founder, engineering leaders, and product managers explaining why their product is safe to use. This is often an unfair fight if your customer's infosec team is on the call and has the knowledge and security expertise to ask hard, technical questions. These questions will range the security spectrum from product security to corporate security and risk management. Hiring a person to own the security function of the company is critical. 

When is the right time to do this? Sooner rather than later! Implementing your first security controls and policies is much less disruptive at 100 employees than at 500. Things like implementing access controls, static code analysis, and starting a vulnerability management program are much easier to get off the ground when dealing with a handful of engineering teams. If your company has dozens of engineering teams without an effective vulnerability management program, it's similar to turning a battleship to get all those teams operating in the same way to secure your product. Avoid the widespread culture shock and begin infosec early; the cost-savings will be dramatic.

Step 1: Your first security hire

Your first security hire will either make or break your infosec program. The initial controls this person puts in place will likely be in place for years. If this is executed well, your company will have the foundation to grow securely. Conversely, if done poorly, engineering productivity will suffer, culture could be negatively impacted, and perhaps most dangerously, you will have the facade of a secure environment that could be full of serious gaps.

There is no "best" way to do this. You could take a top-down approach and begin with a director-level hire and have them build out your team. This could be an effective option if your team has the talent pool, time, and money to do so. Since startups are generally headcount and cash-constrained, we will look at the bottoms-up approach, starting with an individual contributor.

Experience matters when hiring your first security engineer. This person needs to have broad experience in both corporate and product security. Some of the experience you should look for are as follows:

• Experience with startups

• Building a vulnerability management program from scratch

• Threat Modeling

• Cloud Security (assuming your company is cloud-native)

• Secure software design principals

• Securing SDLCs

• Customer-facing experience (this person will interact with your customers in sales calls and should have all the soft skills this entails.)

• Incident Response

• Implementing security monitoring tooling

• Building and managing teams

• Knowledge specific to your tech stack

Next Steps:

The intent for his hire is to come into your company, assess the security risks, and begin laying the foundation of your security program. This person will need funding for procuring tools and additional headcount within 6-12 months. The employee should plan to grow the Infosec team and move from an IC to a PM/TL role.

Important Note - This person should report directly to a CTO or CEO. Putting them into an engineering team, by nature, is a conflict of interest. Engineering teams have deadlines and features to roll out, and your security engineer will likely identify issues impacting these timelines. You do not want your security engineer's findings put on a back-burner by an engineering manager without your executive team weighing in on priorities.

Step 2: Assess the security of your company as a whole

When startups begin their infosec journey, they usually become hyper-focused on their product's security and miss the big picture. While this is important, remember that in most breaches, the initial foothold does not originate within the product the company sells. It almost always falls into the corporate security domain, whether through social engineering, a missed server exposed to the internet, or an unpatched host in a dev environment; these are the low-hanging fruit for an adversary. When figuring out where you will apply resources to level up your security, you need to look at the enterprise.

Choose a framework:

Start with an established framework (or standard) to measure your company's security. There are a few to choose from, including NIST CSF, CIS, ISO, etc. Understand that some of the controls in these frameworks do not directly apply to the typical cloud-native companies that have started in the past five years. The true value of conducting a risk assessment with something like NIST CSF is that it forces your team to look at security aspects that were almost certainly not considered in detail before. 

Executing a NIST CSF is straightforward: you step through all the security functions and score yourself on a 0-5 scale for each. 

One example is ID.BE-4: Dependencies and critical functions for delivery of critical services are established. As you determine your score, you may realize you don't fully have every critical service identified. The first items that come to mind for this control are data back-ups, availability zones, and failover systems, but often overlooked are systems like your IdP, Slack for incident response, CI/CD platforms, Terraform, etc. The number of systems required to deliver products is increasing as companies become more and more tightly integrated. 

Once you complete your assessment with these frameworks, you will receive a baseline score that you can use going forward to measure your progress in improving your company's security posture.

Listen to your customers:

The security questionnaires you receive from your customers are a great data point. Collect these, determine the commonalities, and apply them in step 3 (building your risk register). Enterprise customers have similar compliance requirements regarding the fundamentals, and many will ask for evidence of the same controls. The questions you are asked in sales calls that you are uncomfortable answering should go on this list. Address the common asks, and you will boost your prospective customers' confidence in your ability to secure their data. 

Step 3: Build a risk register

A risk register is a structured document that comprehensively records an organization's potential risks. It typically includes details such as the nature of the risks, their potential impact, likelihood, mitigation strategies, and current status. At this point, you will have three sources from which you can identify risk within your company. This is important because this will inform how you allocate resources and prioritize your security efforts.

Cyber Security Framework: Your first source is the framework results from step 2. This comprehensive review should have identified security gaps in all aspects of your company. The output should provide insight into where your company's security maturity is lacking.

Customer Questionnaires: Next, the set of questions you collect from customers provides valuable insight into what your customers are looking for from their vendors. While these will not necessarily help you gauge risk within your organization, they will help you determine how to make security a "non-issue" during the sales cycle.

Security Hire: Last, your security hire should be laser-focused on identifying gaps within your product and organization. This will be done primarily through threat modeling, penetration testing, and interviewing engineering teams. These gaps will be some of the most important to address since they are directly associated with your product or organization, have tangible technical ramifications, and immediately impact your customers.

Once data from the above three sources is available, it should be compiled into a risk register and prioritized. A critical part of a successful risk register is ownership. An individual owner should be assigned to each risk, with its status tracked. The security hire should own the risk register and track all risks in the future. The security hire should brief the risk register every quarter to stakeholders to ensure corporate alignment on some of the remediation efforts that may impact product timelines. 

Part 1 Conclusion

Consider the above steps as the design phase for implementing your security program. Once you have completed your risk register, you are ready to implement actual technical controls, policies, and processes. Part 2 of this blog series will go in-depth about implementing controls based on the risks you have identified, how to avoid unnecessary spending, and how to get the most bang for your buck out of what you choose to buy.  

Part 2 - Bringing in the right tools