How to `Startup` Security When You Don’t Yet Have a Security Department

Published in

People.ai Engineering

7 min readJul 8, 2019

Part: 1

People.ai is an enterprise-facing SaaS provider. We went from an incubated idea to a Series C-funded SaaS company in three years — in the parlance of Silicon Valley, People.ai is a ‘rocket ship.’ As the head of Security, I’ve learned a few things during takeoff that I hope will help you as you get started.

All start-ups must manage limited resources in the beginning. In a SaaS business, funding first goes to Engineering to build the product, then to Sales to sell it, and eventually to Security as “Departments” are created. But before you have the funding for that, you have to start implementing security — and this is often left to engineers to do.

In this series of articles, I want to offer a roadmap for building a Security department at an enterprise-facing SaaS start-up, (“Security,” from this point on). I’m not going to get into detailed security recommendations, though a few may be sprinkled about.

Where do you begin?

Start with your company size and the vertical you’re in and adjust for your specific situation. For example, if you are a FinTech or BioTech SaaS provider, you’ll have to spend more effort on compliance than less-regulated industries. If you are a SaaS-tech company providing tools to other SaaS companies, you’ll focus more effort on operational security. Keep these things in mind as you adopt a strategy for your company.

What is Security Responsible For?

Security’s responsibilities fall into some or all of the following areas:

Product and service

Secure the infrastructure on which your service runs, manage or direct application security (the code), operate threat and vulnerability monitoring, and perform incident response.

Information technology

Set policies for IT to implement; perform threat and vulnerability management, and incident response.

Compliance (governance, risk, and compliance)

Ensure the company complies with relevant laws and regulations, and with customer obligations. Start-ups are often messy in this area. The longer it takes you to clean your room, the longer it will be before you get to go off to college.

Sales

Help Sales build a prospect’s trust in the company. Complete information security (“InfoSec”) questionnaires, review sales and marketing materials, and educate the Sales Engineering team on how security works in the product and at the company.

Facilities

Make sure the locks and cameras work, the proper protocols are followed with regard to the work premises, and that things like evacuation plans exist and are tested.

The Business Reasons for Security

Security serves multiple business needs, including the following. (In the specific recommendations later in this article, I will reference these business reasons in parentheses.)

Security

These purposes were outlined above.

Compliance

For start-ups between 20 and 100 people, management will realize it needs certain certifications to win the trust of sales prospects. Your first certification will likely be SSAE-16 SOC 2 Type 2. Your second will likely be ISO 27001:2013.

In start-ups between 60 and 100 people, Security should recognize that you have customer, and perhaps regulatory, obligations that go beyond service reliability. For example, you may find that Sales has signed contracts with customers that don’t allow you to use third-party service providers to process customer data, without prior written consent. Another example may be you find new privacy laws require affirmative consent from users for how you use data. Often times, these issues only come up as the start-up takes on larger customers, and grows staff with specialties in areas previously overlooked.

Sales

Since the Target data breach (and other high-profile data breaches, GDPR, and now similar legislation in the United States), medium and large enterprises, and increasingly smaller ones, require Sales to complete burdensome information security (“InfoSec”) questionnaires and pass InfoSec reviews. This significantly lengthens the sales cycle, if not kills it entirely in the last three weeks. I’ll go into some recommendations later in this article on how to address this.

Security at a Start-up of Up to 40 Employees

Obscurity favors small start-ups — those under 40 people — just so long as Engineering follows basic cloud security principles. At this size, a start-up’s biggest security risk is cloud resource exploitation for crypto-mining, file distribution, and command-and-control centers. Yet, as the start-up grows and (hopes it) becomes known, it faces additional, intertwined security issues:

Earning trust with prospects;
Preventing resource abuse; and
Protecting intellectual property and customer data.

A wise management team pours the foundation for a strong Security department well before it has the funds for its first Security hire. (In other words, there is no Security department, yet.)

So how do you run Security without a Security department?

Employing the following practices will allow your first Security hire to also help you sell your service, something critical to SaaS start-ups.

Because companies at this size don’t yet have a Security hire, Engineering is primarily responsible for implementing the recommendations (unless noted otherwise). Keep in mind that the primary reasons to do these things now, even before you have a Security department, is to get through the InfoSec review portion of the sales process. Selling your product or service will be significantly harder, or perhaps impossible, without implementing these recommendations.

Product and Service

Minimize shared accounts. Use the identity and access management system (“IAM”) of your cloud provider. Tie it to the single sign-on solution IT must deploy. (See IT, below.) (Security, compliance)
Choose a hardened base image by a reliable source. Apply security updates religiously. (Security, Sales)
Log security updates. (Sales, Compliance)
Minimize entry points to your production cloud service to one, your application over TLS. (Security, Sales)
Create separate cloud accounts based on function. (This may depend on your cloud provider. In AWS, an account is a separate account with its own set of resources, including IAM and virtual private clouds.) (Security)
Application (Only production services run here.)
Staging (Staging, and non-production infrastructure. No customer or production data.)
Public (All low-risk systems. No connection to the other cloud accounts.)
Other accounts as needed. For example, if you use Apache Spark, your Spark clusters should be in a separate account to which very few engineers have access, with a very narrow tunneled peer connection to virtual private clouds in some of your other accounts — very narrow.
Integrate static and dynamic code checking services into your CI / CD service. (Security, sales)
Create processes by which no developer can promote his or her code to production; Only another developer can do so after reviewing another’s code. (Security, sales)
Run annual penetration testing. (Security, sales)
Run daily internal threat vulnerability scanning. (Security, sales)
Run daily external vulnerability scanning. (Sales, security)
Federate your application. You do not want to be in the business of managing customer identities or credentials. Instead, federate your application with your customers’ identity provider. Use SAML 2.0, OAuth 2.0, etc. (Security, sales, compliance)

Information Technology

Use all cloud services. It’s easier to manage, and likely cheaper, than buying systems and installed software licenses. (Security, compliance)
Do not use local servers, e.g., file servers, printer servers. It’s old school. You don’t need them, and it makes compliance harder. (Security, sales, compliance)
Establish single sign-on (SSO) with a cloud service. (Security, sales, compliance)
Only use Apple Macs. It significantly reduces your endpoint attack surface and reduces InfoSec questionnaire burden. The corollary to using Macs is to enroll in Apple’s Device Enrollment Program. It makes setup, inventory management, and device management easy. (Security, compliance)
Sign data processing addendums with service providers. Nearly all service providers will give you a default DPA. Collect them as you sign and renew contracts. This will greatly help you with compliance later on. (Security, compliance)

Compliance

You won’t have the ability to seek compliance, but nearly all of the recommendations below significantly shorten your path to SOC 2 Type 2 and ISO 27001:2013 certification, which management will soon want.

Write clean, simple policies. (Hint: put them in Confluence or a similar Wiki; Avoid using Word or Google Docs. Management of policies in these solutions becomes unwieldy.) (Compliance)
Document management’s approval of the policies. Set a quarterly management meeting to have policies reviewed. Document these meetings. (Compliance)
Stay highly-organized. Use well-organized folders and consistently-named files. Gold star hint: use YYYY.MM.DD. as a date format for all files at the beginning of the file name, or the end of the name when you have many files with the same filename. Doing this brings many benefits. Files self-organize chronologically. Auditors love this, as it makes audits much easier. (Compliance)
Start a security awareness training program. There are many inexpensive web-based programs available. Set one up immediately. (Compliance)
Enroll developers in OWASP Top 10 training. (Security, sales)

Sales

You will have to complete painful InfoSec questionnaires. This will take the effort of your CEO, Sales, and Engineering.

Use RFP response software. This is hugely helpful. (Sales)
Create a Sales folder, and teach your Sales team to use it. Put your polished security materials meant for Sales in there. (Sales)

Facilities

Integrate building access with your SSO provider. It’s easier than you imagine. (Sales, Compliance)

In the next installment, “40 to 100 Employees”, I’ll discuss how to get SOC 2 Type 2 certification, ISO 27001 certification, and how to get your cat to listen to you.