A Developer’s Guide to Startup Security: 15 Ways to Secure Your Startup (Part 2)

Just a quick skim of news headlines for the word “hacking” can make every person’s heart beat a little faster. The most challenging part is everyone can be vulnerable to startup security threats—whether they’re your customer, your vendor, or your colleague.

In the first post of this series, we covered five common security threats that startups face: data breaches, phishing, cryptojacking, ransomware, and DDoS attacks. Even just one of these hacks was significant enough to bring down Mt. Gox, which was processing over 70% of Bitcoin transactions in 2013, to bankruptcy protection a year later. While the threats are real and scary, we ended on an optimistic note; if you invest in them, security infrastructure can keep up and protect your customers and company.

Here are 15 ways you can secure your startup. And security compounds; the earlier you can implement these methods, the stronger your lasting security infrastructure will be. For every method, we outline what threats it protects against and how you can get started.

1. Assemble an authentication stack

‍Guards against: Data breach

Establish authentication to get the most bang for your security buck.

Authentication, in simple terms, makes sure the person trying to access your app is who they claim to be. Authentication is what separates real users from bad actors posing as real users. We suggest incorporating three core components in your authentication stack: multifactor authentication (MFA), single sign-on (SSO), and password management.

MFA is, as the acronym implies, when you authenticate users through multiple factors. In its simplest form, this is username and password plus a magic link sent to an email address. You can have many more and many different factors, though, up to and including biometric factors, such as fingerprint scans and retinal scans.

Not all MFA methods are digital. A company called Yubico, for instance, provides a physical authentication factor that adds another layer to your authentication stack. The Yubikey is a physical device that plugs directly into a USB port.

‍
When you use it, the Yubikey creates a unique code that you can use to validate your identity—but only once. You have to physically have the Yubikey to generate the code.

The Yubikey is a pretty neat experience, if we do say so ourselves. You plug it in and the device lights up. All you have to do is click the field from the service you’re using the Yubikey for, touch the gold button (it’s a capacitance sensor, so it’s quick), and the code will automatically appear in the field.

The more factors you use, perhaps a combination of a magic link, a physical device, or others, the more difficult you make it for an attacker to breach your business. As cynical as this sounds, your best strategy often boils down to being faster than the slowest person running away from a bear––you can’t be perfectly secure, but you can certainly make yourself one of the harder targets.

SSO is in the same family as MFA. SSO, as we explored in depth in The Developer’s Guide to SSO, is basically when you outsource your auth to someone else. Apps with SSO authenticate users through a service other than their own––typically through a provider (called Identity Providers or IdPs) like OneLogin or Okta.

These companies are focused entirely on authentication, so their service, frankly, is going to be better, smoother, and more secure than what you can build in-house. And if users only have to handle one password instead of juggling many, you can trust them to use a secure one.

Bonus: The SSO login flow is super smooth, so if you want increased engagement, it’s the way to go. That’s why big companies like Slack, Twilio, and Dropbox all use it.

Password management solves the same problem that SSO does: too many passwords. Instead of centralizing the authentication flow, however, password managers centralize passwords. Popular tools include 1Password and LastPass, both of which count consumers and businesses among their users.

The best password managers go beyond being a password lockbox. For instance, 1Password provides access control, which lets you set granular permission for who has access to what, and activity logs, which create an audit trail for user actions.

With a corporate password manager, you can distribute access to all the SaaS apps your business uses without getting pinged every five seconds for the password. Users use one password instead of several. Trust us—it’s worth it.

2. Provision and deprovision users

‍Guards against: Data breach

Set up a user provisioning system to smoothly onboard your users when you hire them, and quickly offboard them once they leave. Why? Unfortunately, threats are likely to originate from inside (or just outside) your company (aka the hacker is calling from inside the house). We know it sounds cynical, but the threat is real: A disgruntled former employee could very well use their credentials to expose sensitive data.

Consider the case of Jason Needham, a former employee of design firm Allen & Hoshall, who downloaded designs worth about $425,000, which he pitched as his own to new clients. Or consider the case of Christopher Victor Grupe, a former employee of Canadian Pacific Railway, who was fired for insubordination and retaliated by deleting essential files, removing admin accounts, and changing people’s passwords.

User provisioning makes it easy to give new employees access to everything they need to do their jobs. User deprovisioning ensures that in just as smooth to protect yourself from the Jason Needhams and Christoper Victor Grupes of the world.

The first thing you’ll want to keep in mind when thinking about user provisioning systems is SCIM, or system for cross-domain identity management. SCIM, as we covered in The Developer's Guide to Directory Sync / SCIM, “sets up a central source of truth for your company’s identity data that can interact with your cloud apps via a REST API.” Essentially, third-party apps talk to a SCIM server (that you maintain) to see which accounts to spin up and spin down. That includes permissions, groups, and more.

From here, there are two options (which I’m sure you’re familiar with): build or buy.

If you want to build, you’ll need, at a minimum, a system that can:

• Add and remove accounts automatically.
• Create and manage permission groups.
• Update attributes and account settings.

Building this is tedious and requires swatting away all sorts of quirks. Dropbox, for instance, lets users sync files to their desktops, so its SCIM integration had to be able to get rid of those files. Your app will probably have a few of these quirks, too.

SCIM is also only one standard among many.

Azure Active Directory, GSuite Directory, LDAP, and Workday are options, too. If you’re building a user provisioning and deprovisioning system, you’ll need to account for all of them.

That’s primarily why many developers choose the “buy” option. Options include Aquera, which offers connectors for SCIM, connectors for other providers, and a native integration with Okta; and (naturally) WorkOS, which gives you the ability to support SCIM, Okta, Azure, and many other providers with only a few lines of code.

3. Use an Edge network

Guards against: DDoS

In the olden days, your server could and would crash from too many requests. Getting that hard-won feature in TechCrunch or that viral Hacker News post could cause the temporary death of your website. More unpredictably, a DDoS attack could overwhelm your server and take it down.

A DDoS attack, as a reminder, is when an attacker leverages an overwhelming amount of traffic to crash your server. You can combat this, and other traffic events, by setting up an edge network to transmit and host data.

Cloudflare sets the standard here. Cloudflare provides an edge network that delivers content and other services as close as possible to the device making the request. Rather than one server (yours) handling all requests from users from who knows where, Cloudflare’s data centers act as go-betweens.

This comes in handy when traffic is high. You can depend on the redundancy of Cloudflare’s data centers—even in the event of a DDoS attack. The very nature of this redundancy provides some protection against DDoS attacks, but Cloudflare also provides an “I’m under attack mode” that provides greater safety. In this tutorial from A2 Hosting, the author outlines how you can enable this feature in the software section of cPanel.

You use this feature when—you guessed it—you’re enduring a known attack. When enabled, your site will show the below image as Cloudflare checks the legitimacy of the incoming traffic.

‍
With Cloudflare, you can also whitelist certain IP addresses that you trust, and you can block all others. It’s the go-way to get the protection of an edge network.

4. Secure your APIs

Guards against: Data breach, DDoS

Your mobile app API is a threat vector––and a dangerous one at that. By their nature, APIs often directly connect the logic of your app to user data. Without the right security measures, hackers can commandeer your APIs for criminal means. If you have a billing API, for instance, a hacker could use it to direct funds to their own account. Secure your API to protect it from malicious attacks.

Threats against your API include:

• SQL injection: By adding SQL statements to an entry field on your API, hackers get your database server to do something it’s not supposed to do.
• Cross-site scripting (XSS): Hackers set up a client-side script on a page that users visit, so when the script executes, it does something you don’t intend.
• Man-in-the-middle (MitM): Hackers interrupt the communications between two systems and intercept the information moving between them.

Security threat researcher Debbie Walkowski provides a whole host of steps you can take to secure your APIs via f5, seven of which we highlight below:

• Take an inventory of your APIs: This one’s simple but effective—and essential. Take stock of all the APIs you have, especially if any are publicly available. Once you have a DevOps engineer or team, they can manage them, but for now, build an inventory so you can add as you go.
• Use authentication methods based on proven protocols, like OAuth2.0 and OpenID Connect: When APIs don’t enforce authentication, which, as Walkowski notes, is often when it comes to private APIs, then hackers can break in pretty easily. When you build or buy an authentication system, choose one that relies on proven protocols.
• Use TLS to encrypt traffic: TLS, a popular encryption protocol, is an essential step. You might not use it for some data that isn’t sensitive, but you’re best served using it for everything else.
• Review API data exposure: You and I both know your APIs sometimes have keys, passwords, and all sorts of stuff you don’t actually want people seeing. Review your APIs before making them publicly available. If possible, adopt a scanning tool that can do it for you.
• Validate inputs: Walkowski breaks it down to one simple rule: “Never pass input from an API through to the endpoint without validating it first.” Follow it.
• Use a web application firewall: When you implement a web application firewall, ensure it’s one that can understand API payloads.
• Use rate limiting: To protect against DDoS attacks, set a limit for how many requests you’ll allow.

It’s worth zooming in on rate limiting. J Simpson, writing for Nordic APIs, provides some good examples.

In it, he lays out different rate limits for authenticated and authenticated requests, as well as showing you how to check your current rate of usage.

LinkedIn does something similar in its rules for developers, where LinkedIn explains why there are different rate limits for different endpoints.

The easiest way to limit API requests, as Simpson explains, is to set a time-out and send a clear HTTP 429 ‘too many requests’ error message explaining what happened to your users.

5. Use secure coding best practices

Guards against: Data breach

Security ranges from the highest organizational levels to the lowest, on the ground levels, namely, code. Develop with best security practice in mind, perform regular (ideally, automatic) source code analysis, and perform regular (ideally, automatic) vulnerability tests.

Robert Seacord, tech director at NCC Group plc, shares ten secure coding practices, which we summarize here:  

• Validate inputs from all data sources you don’t trust. Be especially wary of external data sources, which, Seacord notes, include command-line arguments, network interfaces, environmental variables, and user-controlled files.
• Use the highest warning level possible from your compiler to compile your code. Don’t eliminate warnings by modifying the code.
• Architect with security policies in mind. For example, Seacord advises that you divide your system into subsystems, each with distinct privileges, if the system you’re using requires different privileges at different times.
• Keep your design simple and small. The more complex your design, the more likely there will be implementation and configuration errors.
• Your default is denial. Your system should deny access unless it’s permitted.
• Follow the “least privilege” principle. Restrict your processes to using the fewest privileges necessary. If a process requires more, limit how long that access is available.
• Sanitize your system-crossing data. Hackers can invoke unused functionality in commercial off-the-shelf components via injection attacks. Sanitize all data that you pass to complex subsystems.
• Build in redundant defense practices. For example, Seacord advises that you use these best practices and use a secure runtime environment. This will lessen the chance that vulnerabilities will be exploitable in an operational environment.
• Use quality assurance processes. An effective quality assurance (QA) practice includes techniques like fuzz testing, penetration testing, and source code audits.
• Adopt a secure coding standard. This one’s simple. In Seacord’s words: “Develop and/or apply a secure coding standard for your target development language and platform.”

Ideally, you’re not on your own when it comes to secure code. Supplement these best practices with source code testing tools (OWASP provides a giant list here). You can also use continuous integration testing tools. Open-source tools include Jenkins (the most popular), Buildbot, and TeamCity.

6. Set up access control

Guards against: Data breach

Controlling access to the inner workings of your infrastructure is foundational to your startup’s security. As your company expands, you’ll wish you had set up these policies and tools earlier. The earlier you can control access, the better you can maintain control as your company grows.

Keep in mind is the difference between RBAC and ABAC, the two main ways to set up access control (see our article RBAC vs. ABAC: What is the difference between access control models? for more details). To summarize, RBAC—or role-based access control—uses predefined roles that an administrator sets up to determine varying levels of permissions. ABAC—or account-based access control—uses policies to set permissions from attributes.

RBAC will use roles, like “developer” or “accountant”; ABAC will use personal attributes, like username and team; resource attributes, like file name and data sensitivity level; and environmental attributes, like device and data. It gets more complex from there.

Two things are worth drilling down to here:

1. OAuth access. GitHub provides a tutorial that shows you how to enable OAuth App access restrictions here. If you want to prevent apps you don’t trust from accessing your company’s resources (and you do), you can enable OAuth App access restrictions. That way, you can still allow members of your company to use OAuth Apps for their own accounts.

It’s as simple as clicking the “Restrict third-party application access” button, which is located in a "Third-party application access policy" window in organization settings.

Simple steps like these are important.

2. There is a range of products available to help you manage access control. Cloudflare Access is worth highlighting. Most companies’ security strategies are perimeter-based, meaning security focuses primarily on the perimeter. The weakness there is that if someone breaches the perimeter, all that’s inside becomes their playground. Cloudflare Access, and tools like it, instead ensures that every request, no matter what, is authenticated, authorized, and encrypted.
7. Set up firewallsGuards against: Cryptojacking, data breach, DDoS

Firewalls help you control network traffic. Firewalls can either block suspicious traffic or route it to tools that can properly inspect and approve of it. This routing is typically based on rules like source, destination, protocol, and size. Some firewalls can even inspect packets for malicious code before routing or approving them.

According to Tony Asher of consulting firm Asher Security: “A good firewall implementation strategy will include a progressive approach to enabling features on the firewall, starting with the foundational basics and building on that so that the firewall doesn’t cause the kinds of latency issues for the network users.” The goal is to slowly build up a series of firewalls that keep your network secure without causing latency.

The major question is where to place firewalls. There are numerous places on your network where you can put a firewall, including the following:

• Your external perimeter: This is the expected place for a firewall. A firewall here applies rules for traffic passing from the Internet to your internal network, commonly called “inbound traffic.”
• An endpoint: Endpoints are workstations or computers. Users install firewalls like they would other software and such firewalls apply similar rules that an external perimeter firewall would.
• A DMZ: This term stands for demilitarized zone and refers to some part of the network that is separate from the internet and the internal network. A popular use case, as Asher points out, is to segment away data hosted for your web servers. A firewall here can allow external users to query it and internal users to add to it.
• Your applications: This is a relatively recent location for firewalls. You can place them in front of web apps that are externally facing. These take a web application firewall, or WAF. These protect your app from malicious traffic.

With firewalls, you’re better able to block and inspect potentially malicious traffic before it affects your systems.

8. Automate patching

Threats: Data breach

The tools you use regularly release patches that can fix security flaws and vulnerabilities, but these patches are useful only if you install them. But the number of patches coming out can quickly become overwhelming, especially if you don’t have an IT administrator. If you’re using a Linux system, patching can become “a full-time job.”

As such, it’s best practice to automate patching. Automatic patches take effort off your shoulders and ensure that your systems have their required patches as fast as possible.

Automation is easier said than done, however. Luckily, there are tools like Puppet and Bolt that make it easier to automate and orchestrate patching. In a useful tutorial, Tony Green, a UNIX systems administrator, walks through how you can automate patching for Windows and Linux.

“Tracking down affected services,” Green writes, “requires manual effort, specialized tools, custom tool development or a combination of all three approaches.” Beyond that, applying those patches can take a bunch of tedious, manual work. Work a creative developer doesn’t need to do.

Puppet, if you don’t know, is an open-source tool that lets you better manage and deploy configuration changes. Linux and Windows users are its most common users, and they use it to manage more than one application server at the same time.

With Puppet, as Green demonstrates, you have the framework to build a super-effective tool for patch deployment and reporting. Puppet provides a way to centralize data and keep it accurate, as well as an RBAC system, a web console, and a API.

9. Use an ad blocker

Threats: Cryptojacking, ransomware

We’re guessing you already use an ad blocker—27% of all users did in 2018, and we assume the proportion is higher for technical users. But if you don’t, we’re here to tell you that you should.

Ads aren’t just annoying—they can also be the source of all sorts of threats, including two we mentioned above: cryptojacking and ransomware. The best way to deal with these threats is to install ad blockers that either block ads or inspect ads for malicious code.

Let’s focus on one threat here: cryptojacking. Cryptojacking, as we covered before, is when malicious code (in this case, inserted via ad) that commandeers your compute resources and uses them to produce cryptocurrency.

Luckily for us, one of the most popular ad blockers on the market, AdBlock, started including a filter list to stop cryptojacking back in 2017. On their blog, the AdBlock team writes that they counted almost 4,000 domains with cryptojacking scripts. One week, they counted more than 31 million scripts blocked.

If you want to dig deeper into this stuff, AdBlock offers a resource page where you can see the requests that sites are making and what AdBlock is doing about those requests. There are also customization settings, so you can create a whitelist or a list of exceptions.

10. Educate users on threats

Threats: Cryptojacking, ransomware, data breach, phishing

One of the best tools in your arsenal isn’t an app––it’s education. Explain to users in your company the threats they face and how they can defend against them—even if that just means not clicking on a phishing link.

The key is creating a communication strategy that’s scalable. When you’re a team of 10, an @here in Slack might be all you need in order to warn your company about an incoming (or present) threat. But once your startup starts taking off, and you experience that hockey-stick growth of hiring, you’ll want to be able to communicate in a way that’s more effective and requires less effort.

There are two major ways to build security knowledge into your growing company: training and documentation.

Many of the threats we’ve discussed already are threats only because of user mistakes. Phishing wouldn’t work if no one clicked phishing links, but, of course, they do. If you want to protect your company from those threats, you have to build security training into your employee onboarding program.

Kaspersky, a cybersecurity provider, has an excellent ebook covering 10 tips for educating employees. One key takeaway is the need to talk to employees about security on a regular basis. It can’t be something that only comes up when a threat is imminent. As they say, an ounce of prevention is worth a pound of cure.

Training is hands-on and time-intensive but worthwhile. It’s not, however, a complete strategy. Especially as work goes remote and communication goes asynchronous, it’s just as important to create comprehensive documentation that includes all your security policies, procedures, and rules.

11. Capture audit logs

Threats: Data breach

As we wrote in The Developer’s Guide to Audit Logs / SIEM: “App security means app visibility.” And visibility means audit logs. Audit logs track events like logins and password resets, as well as what data someone accesses and when they access it. Logs expose these data in a UI and/or API so devs or admins can examine them at scale.

An event, as we covered in our guide, might look like they do below:

Another key aspect of logs worth repeating here is that log events aren’t analytics or observability events. The events will overlap, but there are different use cases for reach, meaning the way you handle each set of data has to be different too.

We recommend capturing events like these:

• Login / auth
• Data access
• Billing
• Search / navigation

And we recommend formatting logs such that they capture:

• An actor
• A group
• An action type
• Timestamp

Whatever you do, make sure you standardize your log formats internally. There are external standards, such as Common Event Format (CEF) from ArcSight but the most important is having a standard so that things are consistent.

Once you have a standard, set how long your retention window will be and where you’ll store the logs. Typically, companies keep logs for 90 days but sometimes allow clients to pay for longer windows. In terms of storage, we usually find that companies choose relational stores like Postgres or search systems like Elasticsearch.

Once you have a standardized format and a retention window set up, you’ll want to work on a front end that exposes all this data. This could be simple (a table with events), or it could be complex (an admin panel with search and filtering features).
‍

We’ll repeat what we covered in our guide: “What you build depends on the use cases your customers have: detailed frontends are useful if your users are going to interact with audit logs directly in your app, but can be overkill if you’re dealing with much larger customers who will want to export these logs to a different tool anyway.”

Now, let’s touch on those “different” tools.

No dev wants to spend their time digging through the audit logs of hundreds of thousands of users. Eventually, you’ll want to invest in what’s called a security information and event management (SIEM) tool. These tools take audit logs and provide all the search, organization, and visualization features you need. Some tool options include Splunk and Sentinel.

Audit logs give you visibility into what’s actually happening across your app. Without logs, a data breach will leave you lost; with logs, you at least have a chance of tracing where the breach came from, who did the breach (or who compromised your security), and how you can patch the vulnerability.
‍

12. Set up an IT asset inventory system

‍Threats: All

An IT asset inventory system is harder to make the bigger your company gets, so it’s best that you do it yesterday. Once you have a system set up, adding to it is easy, and, before you know it, you’ll have a system that’s ready to scale.

In the old days, an inventory of this kind referred exclusively to hardware assets; think the laptops that IT would give out on your first day. Nowadays, software is even more important for you to track. Enterprises are worried about what they call “shadow IT,” where employees adopt software without permission (gasp). This is no longer a crime; this is a business model (see our articles on Dropbox and Twilio to see how they did it).

The key, as Twilio CEO and co-founder Jeff Lawson explains in his book Ask Your Developer, is, “Developers are usually the first to know what’s new and interesting in this digital supply chain.” If you’re a CTO, or a CTO-in-all-but-name, the goal isn’t to turn around and treat your team like an enterprise would. Instead, Lawson says, “Ask your team if they’re secretly buying these services of the digital supply chain.” And, he adds, “Understand why, and figure out how to formalize their ability to do so.”

The goal of developing an IT asset inventory system isn’t to become Big Brother and start restricting what people can and can’t do. The goal is to make device and software tracking possible so that you can stay ahead of any security concerns. Otherwise, when a data breach does happen, you’ll be left scrambling, wondering where the vulnerability is (or, more likely, stunned at just how many vulnerabilities there are in an unmonitored system).

Solutions range from the simple to the complex. When you’re small, you can make do with a simple spreadsheet. As you grow, you may want to implement a dedicated tool. Options include this free asset management tool from Spiceworks and other open-source tools, like SysAid IT Asset Management and GLPI.  

13. Audit your SaaS stack

Threats: All

This step dovetails nicely with the previous step.

According to a Blissfully report, SaaS apps are, well, popular. On average, one employee uses eight SaaS apps. Companies with fewer than 50 employees have about 40 total SaaS apps; companies with 200 to 500 employees use, on average, about 123 SaaS apps. Every single one of these apps is a threat vector.

Blissfully also states that nearly 75% of companies with over 100 employees have SaaS apps with no billing owner. If there’s no billing owner, we can safely guess there’s no one thinking about that app’s security. That’s why it’s important to periodically audit your SaaS stack and interrogate the use of each app.

Take a close look at each app and ask these questions:

• Is it SOC 2 compliant?
• Does the company behind the app have a security team? If not, what security tools do they use?
• Where is it hosting your data? If a private data center, how secure is it? If third-party cloud, how secure is that provider?
• Does it provide backup capabilities?
• Is the data encrypted?
• How well can you audit usage?
• Does it support MFA or SSO?

This is a useful exercise for two reasons. The primary reason is that it will expose what apps might be riskier than they’re worth. Do a simple risk / benefit analysis. Don’t be afraid to get rid of apps that endanger you more than they help you.

The secondary reason is that it puts you in the shoes of your future customers. Ask your app these same security questions. Your customers will be asking the same questions, so make sure you have good answers.

14. Write a security plan

Threats: All

Treat security threats as inevitable and your response as an algorithm: If threat A, then response B.

Write a security plan that includes :

1. Regular security reviews.
2. An incident response plan.

Your security reviews should be consistent (monthly, quarterly) and comprehensive. Cryptojacking, for instance, can often be caught during these reviews. Travis Farral, director of security strategy at Anomali, explains that when cryptojackers inject malicious JavaScript on a web server, "The server itself isn't the target, but anyone visiting the website itself [risks infection]." With that in mind, look at your system carefully, and keep an eye on changes, either file changes on the web server or changes to the web pages.

Security consultant Ryan McGeehan provides a good boilerplate template for incident response plans. They include, essentially, 9 steps:

1. Escalation: Give all employees the ability to sound the alarm, such as a security@yourcompanynamehere.com email address they can email or a dedicated Slack channel.
2. Severity: Educate employees on the differences between low, high, and severe events.
3. Internal issues: Give employees a direct route to who they need to contact, including the founder/CEO.
4. Compromised communications: Give employees an “out of band” communication solution, ideally something encrypted.
5. Response steps: Outline a series of steps that directly responsible individuals can take to investigate, contain, remediate, and document.
6. Team members: Document the names and contact details of anyone in the escalation path.
7. External resources: List your forensics partners, lawyers, law enforcement, and PR.
8. Run books: Make manuals for all the steps you need to take, such as changing corporate passwords.
9. Required retrospective: Do a retrospective so you can learn what happened and how you can prevent it in the future.

With regular reviews and a playbook for the incidents you may or may not discover during those reviews, you can trust that you’re about as prepared as possible.

15. Outsource what you can’t build today

Threats: All

Technical debt is a known problem, but in the cybersecurity world, it often takes on the jargon / flavor “security debt.” Security debt is when you avoid investing in security early and then face the uphill battle of fixing security problems later.

Compare the cost of buying a security product against the cost of building it yourself and against the cost of devoting resources to building features that aren’t core to your product. According to Jeff Lawson, developers should build whatever differentiates your product and outsource the rest. With the API economy in action, devs don’t need to build everything from the ground up; you can source security tools like Ford sources tail lights or like Apple sources LCD screens.

And you won’t be alone—far from it, actually. A Deloitte study found that nearly all companies outsourced a portion of their security operations.

Lawson’s heuristic leaves a lot of components to outsource, but we want to highlight four in particular:

• Vulnerability management is the proactive prevention and mitigation of vulnerabilities. Startups rarely have the expertise in-house to recognize the wide range of threats out there.
• DDoS defense can be outsourced in two ways. If you’re small, and traffic is low, you can use the services your infrastructure provider offers. Rackspace, Amazon, Cloudflare, and AT&T, for instance, all provide DDoS protection. If traffic has the potential to be high, and the threat of long outages is big, you may want to invest in an anti-DDoS tool, such as Akamai, Verisign, or Radware.
• Authentication is a solved problem that you don’t need to solve again. Authentication is intricate, complex, and finicky. And it’s as essential for security as it is for user experience. It’s an easy outsourcing choice.
• SIEM: By the time you have hundreds of thousands of users, sorting through logs manually won’t be practical. Instead, get a SIEM tool that can ingest logs in such a way that they become searchable, organizable, and viewable. Options include, as mentioned earlier, Splunk and Sentinel.

A too-literal interpretation of Lawson’s rule would lead you to believe in outsourcing it all. While you can and should outsource a lot, that doesn’t mean everything. Your security strategy, for instance, is best in-house. Only you know your company inside and out, so only you can really put together an effective security strategy. The security of your software architecture should also remain in house for similar reasons. You know the code base, so it’s your responsibility to develop with security best practices in mind.

Early, consistent, startup security pays big dividends

Security is hard to invest in because, unlike other investments, which will produce short and long-term results, a security investment ideally produces ... nothing. There is your team’s and customers’ peace of mind that comes from nothingness, and the sense that your startup remains secure. There’s a chance, however slim, that you could remain secure by luck alone, but the data isn’t in your favor. Instead, invest now, and reap the returns of not having your data breach featured front and center on TechCrunch’s homepage.

If you need an extra incentive, consider Enterprise Readiness. When you move upmarket, big businesses will want to know they’re dealing with a secure partner. Taking steps like the ones listed throughout this article prove that your product isn’t some flash-in-the-pan feature—it’s a product they can depend on.

‍