This is the third part of a three-blog series on startup security. Please have a look at part one and part two.
New companies often struggle with the question of when to start investing in information security. A commonly heard security mantra is that security should be involved since the very beginning and at every step along the way. While this is obviously true, it is quite detached from reality and provides little practical guidance.
Frameworks such as NIST CSF and CMMI ratings help an organization evaluate the current state of their security program, but they are heavy on policy and not worthwhile for a startup where a security program does not yet exist. So when should a company run its first vulnerability scan, perform its first risk assessment, have its first penetration test done, integrate static analysis tools into its CI/CD pipeline, deploy its first IDS, write its first security policy, hire its first CISO, stand up a security operations center, etc.?
A common flawed approach is to put off answering these questions until a future date when the company hopefully has the time and money to start thinking about security. This approach is never properly executed because new priorities and expenses will inevitably continue to displace security.
Besides, some founders need a fully functioning product with a growing userbase to raise any funding in the first place - At this point it is already too late to start addressing security. Another common practice is to reactively implement security whenever its necessity becomes apparent due to business requirements, regulatory requirements, or in the worst case, a breach.
COVID-19 caused a sudden surge in the use of remote collaboration tools, some of which gained millions of users practically overnight. Some of these products were unprepared for the influx of users and, consequently, attackers, and were caught off guard by a barrage of security issues ranging from privacy concerns to ineffective access controls.
The best way to ensure a better approach to security is to always have an evolving security plan with set milestones. The plan need not be complicated or fully developed but should contain commitments to be kept. On day one of a new company, the plan might be to reach out to a friend who works in infosec to have a conversation about developing further plans within the first month. At first, the security plan will consist largely of steps required to develop the plan itself. It will take time before the plan resembles a working roadmap or documented policy.
The following is a basic example of how a security plan might develop over time for a new software company:
Day One:
- Before the end of the month, reach out to a friend who works in infosec to discuss security planning.
- Locate some resources to better educate the team about application security before completion of POC.
- Identify any compliance regulations applicable to the business.
One Month in (Design and Initial Proof of Concept):
- Research and implement IDE linters for security.
- Research and implement static analysis tools for CI/CD pipeline.
- Determine security requirements related to user data collected and handled in the application.
- Determine industry standard practices for mature companies in the sector.
- Create a list of security tasks that must be completed before initial release.
- Create a regulatory checklist for compliance.
Leading up to Initial Release:
- Establish a process for periodic code reviews.
- Remediate all important findings from static code analysis.
- Determine and create necessary security documentation for external consumption.
- Draft a security roadmap which addresses policy creation and third-party security services/products.
- Complete all required items on the regulatory checklist.
This is simply an example that might apply to a software company, but it is important for a company to understand its own risks and priorities. Other companies may be more heavily focused on device and infrastructure security, while others may be more compliance-driven at first. There are many security checklists or templates online that offer several worthwhile security controls for startups, but it is important to understand how they apply to your organization to ensure that the right controls are effectively implemented.
The tasks in these example plans can be carried out by most development teams in a day or two and can be tracked on a Kanban board along with other priorities. They also contain tasks to continuously evaluate and evolve the plan as the company moves forward. In performing these tasks, the team will undoubtedly become better educated in the security concerns that affect their startup.
As the company progresses, however, it will hit a point where the security tasks and associated risks become too much for the existing team. At this point, the company must hire security-focused leadership and staff, and the knowledge gained from the initial phase of addressing security internally will surely help in ensuring that the right team is brought onboard.
Perhaps the most important factor determining the effectiveness of a company’s security controls is its culture surrounding information security. This crucial part of company culture begins at the earliest stages with the founding team and can be very difficult to change once set. By incorporating security responsibilities into its processes early on, founders can take an active role in promoting security consciousness throughout their team and better position the company to avoid costly security issues going forward.
This article is part 3 of a 3-part series on startup security. Parts 1 and 2 focused on how startup culture affects software security and the anatomy of a software vulnerability. Part one and part two have been published.
