6 InfoSec Practices Your Startup Needs Now

Early-stage startup life is about moving fast and breaking things. But eventually, your startup will hit an inflection point that requires deeper signaling of reliability to larger, more diligent customers. If you currently sell into mid-market or enterprise companies, you already know about the RFP and Information Security (InfoSec) review process. InfoSec reviews have grown in scope and complexity with broadening product offerings and stricter compliance requirements. InfoSec is an iterative process for all companies, there is no one size fits all process to running a secure startup but you should look for good heuristics and practices to start with.

B2B technology companies face the daunting and tedious tasks of InfoSec reviews, and let’s face it, you get asked the same questions over and over. So implementing InfoSec processes early in your company’s life will save you hundreds, if not thousands, of hours in the long run. The following six items are must-have practices for any startup taking the plunge into selling into the B2B big leagues:

1. Data Loss Prevention

The number one thing prospects and customers care about is losing data. While data breaches resulting from legitimate hacking make great headlines, they are much less common than internal employee lapses. Whether a disgruntled employee is attempting to steal customer lists or a new intern accidentally attaches the wrong zip file to an outbound email, your team will need to know and stop this from happening. DLP (Data Loss Prevention) is a blanket term for tools that monitor the outbound data flow from a system. DLP tools come in a few flavors and cover a range of systems, from email to cloud infrastructure.

The first point of failure for many companies comes from their inbox. Most startups today are using Google Workspaces as their email and document management tool of choice. Luckily, Google has made it easy to setup basic DLP rules. Do this from day one. Overly strict rules may create challenges like sending a PDF to a prospective customer, so you may need to tweak the sensitivity and file types you want to block.

Email is not the only threat vector from an InfoSec perspective. Cloud infrastructure that teams use to hold customer documents or files, like AWS S3, Google Storage, or Azure Blob Storage -- needs to be monitored. Beyond the basic permission restrictions that prevent improper access, deletion, or modification, monitoring for network egress (e.g. download or improper transmission to some other service) can be very tricky. It is rarely a viable option to lock down data storage completely. At some point, someone (or some application) will need access to the data.

Luckily, in recent years, more intelligent services have sprung up to monitor network traffic in and out of a given cloud account. AWS offers two first-party services that cover this area: AWS Guard Duty and Macie. My personal experience with the latter has been relatively poor given the steep price tag. Guard Duty, on the other hand, provides anomaly detection alerts based on user access patterns. This has been a go-to service for the past several startups I have worked at and is a less expensive operational practice for monitoring data leakage.

Keep in mind, DLP rules and processes will vary depending on the data your company captures, the lifecycle of maintaining that data, and the types and locations of the customers you serve. As long as you have some process to prevent data leakage, you will be able to get past these questions in your security reviews.

2. Encrypt Everything

Encryption is an inevitable component of security reviews, so you need to start encrypting everything 一 even if you are a team of one.

First, encrypt all team member laptops’ main storage devices. For Mac users, this is a simple setting. Eventually, your team will need to prove you enforce this level of encryption. Device management technology such as JAMF or JumpCloud provides a robust way to ensure all company laptops are always patched and encrypted.

Also, be sure to encrypt and backup your databases and file servers at rest. FYI, Google Drive does this for you out of the box, using industry-standard 128-bit AES keys to encrypt files. For cloud-hosted databases and storage work with engineers to ensure SSE (Server Side Encryption) is always toggled on.

Bonus points: Speak with your engineering team to see how difficult it would be to provide each customer with their own unique encryption key that allows them to control their data. This doesn’t work everywhere but is a huge plus to any customer reviewing your security practices. This practice also provides your team a quick and dirty way to remove a specific customer's data by simply destroying their encryption keys without running delete commands on your database.

3. Think Through Onboarding/Offboarding Well Ahead of Time

Besides providing a good experience for new hires, having on-boarding and off-boarding processes clearly outlined will show prospective customers that your company is a well-oiled machine. Before you have your next hire in the door, sit down and pull together a checklist. This list should include account access and permission levels, first-day paperwork, and initial meetings to set up. If you don’t know where to start, Notion has some good templates.

During onboarding, account creation should be explicit and documented. You don’t need an internal Jira ticketing system. Simply send emails to the system owners (e.g. your VP of Operations or IT) that indicates who is getting access to what, and what level of permissions they require.

Offboarding should be an even tighter process, particularly regarding who owns the process and is accountable for access removal. This is an area InfoSec reviews will examine closely. Clear proof of access removal should be stored and maintained for all offboarded employees. And physical devices should be in hand within hours of an employee leaving your organization. All your Data Loss Prevention practices go to waste when a disgruntled former employee walks out the door with his laptop.

4. Create an ISP and DR Plan

Fledgling startups often balk at the idea of having corporate documentation. The “move fast and break things” mantra makes a great bumper sticker, but won’t fly when it comes to dealing with sophisticated customers. For that reason, you should develop two documents for internal controls the day you have your first serious customer: an Information Security Policy (ISP) and a Disaster Recovery Policy (DR Policy).

An ISP is basically your InfoSec bible, a formal document that outlines all of your companies best practices: from IT asset management to email DLP monitoring to software development and deployment processes. It should cover escalation cases and documentation processes during a security event as well. . Review your ISP annually, at a minimum, with a formal meeting between all stakeholders (typically a Head of Operations, Engineering, and/or IT). Every update to the ISP should be logged and the document should be versioned.

Hopefully, you never need to enact your Disaster Recovery Plan, but having this policy will bring peace of mind to your customers for when that earthquake finally does knock out one of your data centers. Your DR plan should include clear steps for maintaining data and service reliability in the event of a disaster. Not only does this prove you can restore backups, it also shows you have access to other facilities for application restoration, and a clear reporting chain for responsibilities. Set an annual calendar meeting to run through mock DR scenarios and document everything.

5. The Same Damn Machine for Everyone

If you are early enough in your startup’s life and have not yet allowed multiple types of laptops or computers in the door, don’t start this bad habit. Device management is one of the most time-consuming operational components of a growing startup and can get very onerous if you allow for multiple device types. I am sure there are plenty of software engineers out there that will tell me, “But actually…”. But actually nothing. Don’t allow for different device types unless you want your IT Operations to become a living nightmare. Pick one: Mac, Windows, or if you are a real renegade, Linux, and stick with it for all current and future organizational devices.

6. Keep Data Flow Diagrams Updated

Every InfoSec review will ask for a network diagram. For early-stage companies, this is an administrative burden, given that product data flow and networking are constantly changing. Your engineering leadership should review architecture diagrams quarterly, at the very least. For most teams, a data flow diagram is more than sufficient, indicating what data moves between services and how that data is treated at rest (e.g. encryption type).

One of the best tools I have found to manage a clean diagram of cloud resources is Cloudcraft. Not only will you be able to build out your cloud infrastructure diagram, but you can even use the tool to generate infrastructure code (e.g. CloudFormation, Terraform). Another team favorite has always been Draw.io. It has a seamless integration to Google Drive and offers easy cloud-specific diagram features for free.

Remember to keep your data flow diagrams as clean as possible. Diagrams should always include encryption standards upheld and private/public network designations to reduce the number of questions you get back from the reviewers.

Small teams may not have the time or money to tackle all of these processes at once. But having a human process that replicates some technical security practices can be a sufficient stand-in during an InfoSec review with a customer. The goal with these 6 steps is to show that your company is at the very least thinking about how to mitigate and control operational risk vectors.

Still have questions? Reach out to Dan!