A pretty useful, logical and sensible list. I'd be actually surprised if most SaaS startups were NOT doing this. As a one man show (recently doubled in size to TWO!), I've ticked off nearly everything on here.

One question though - is on the multiple domains bit. Not sure how several separate domains is better than one domain utilising subdomains for API etc.? Intrigued about the 'secret' internal domain thing, and I guess it would apply to larger organisations.

I'd be interested to hear how many startup founders here have a separate internal domain name for back office stuff related to their web offerings.

Might not contribute much to the discussion, but I found this pretty sad:

- Mac users can encrypt their drive with 1 click.

- Windows users would need the Pro version and prefer laptop hardware that supports TPM.

- Linux users would require disk reformatting

I believe that's slightly misleading. Enabling LUKS on Linux would require a re-format, but there are ways to encrypt only your home folder without a re-format, which is all macOS does.

I think FileVault 2 [1] has been doing full-disk encryption, not just the home folder, since OS X Lion.

[1]: https://support.apple.com/en-us/HT204837

Yeah, but I have a lot of stuff outside my home folder. Including /etc/passwd.

submit a PR

Good advice but this is a little dubious "For other internal communication use Slack". Use slack because it is beautiful and free, not because of security

I've found the best results is to use Slack as a central communications repository, whilst still using other tools for better management. Otherwise Slack itself can still get noisy and distracting if it is the ONLY method of communication.

For example, we use Trello for feature planning and tracking marketing activities etc., but have Trello post to a specific channel in Slack also.

Additionally, we use Intercom + Helpscout for customer support, and have those posting to a support Slack channel as well. Then there are the various Amazon reporting and deployment services which also post log messages to Slack.

In a nutshell, I can jump on Slack to check the overall 'big picture' view of my SaaS, but not have things get lost in the noise.

Older employees, and some managers, I found prefer email in many cases. I still request them to use slack

Call me an old fart but I much prefer email.

Email gives me a reminder to keep me organized.

And the two teams I worked on that use slack killed productivity by chatting all day and sending animated gifs.

Plus, people expect email to be asynchronous. With slack, I get a mixture of immediate and asynchronous requests. So every message breaks my flow while I determine the priority level.

And... Apparently after enough time, people come to expect slack to be asynchronous too.

> And the two teams I worked on that use slack killed productivity by chatting all day and sending animated gifs.

That sounds much more like a people problem than a technology problem, if that's how they chose to spend the majority of their time on the job.

I know. We use emails for some meeting summary. But you can't ignore the fact that many attacks start with phishing, and slack is free from that problem

Slack is not free of the problem whatsoever:

https://arstechnica.com/security/2016/04/hacking-slack-accou...

http://www.businessinsider.com/slacks-security-breach-may-be...

http://www.networkworld.com/article/3123727/collaboration/th...

Those three links don't really relate to third parties getting unauthorised access through phishing by leveraging Slack. Slack has plenty of security issues, but you're not proving phishing by any of those sources. It can potentially make you more vulnerable to phishing, but that's not the same thing.

The links in question relate to:

* Searching on GitHub for Slack API tokens

* The Slack database hack

* How the rise of ChatOps can open you up to many more issues if someone gains access to employee's Slack accounts and the risk of third-party applications which might open up things you do to more entities than you realise

I know almost no one who prefers Slack: people I work and worked with find it messy and rather use Skype for calls, some issue tracker and if required email for follow up. For both software related and other tasks alike. Not sure it is related to old.

A few remarks/questions

> Stop using disk-on-keys

never heard that phrase

> Buy at least 2 or 3 domain names

I don't really understand the whole paragraph - or fundamentally disagree with your reasoning. Of course there are some upsides (regarding security) of splitting stuff over a few domains but there's a lot of reason why you wouldn't do that. I think this is written too harshly as "Do as I say" without proper explanations and nuances of the details.

> Monitor your endpoint's public certificate expiration date, to detect prevent certificate expiration.

typo? missing "and"? remove "detect"?

> By default AWS users choose Oregon (us-west-2).

Highly misleading. Or is your advice only relevant for US companies? I'd also say this is false for many people who have an international market leaning towards Europe, not Asia - then us-east is often better.

> Using git would allow you to add outsource/freelance developers for a limited time, by giving and then revoking commit permissions.

Non-sequitur unless you insert "easily". Maybe. I don't disagree that git is the way to go, but your reasoning is nonsensical here. We did exactly that with CVS and SVN 15 years ago.

> Every service you use requires a 2nd authentication factor (2FA).

This is under "your first customer". Was this meant to be "should require"? Are you talking about the XaaS you (the company) are using? Are you advocating that your users use 2FA with your product?

> Antivirus

No, don't.

All in all some good points, but could use some clean up. You're lumping things together from varying degrees of technical expertise - also some paragraphs are highly detailed (and thus, sometimes miss to convey the bigger point) and others are pretty sparse.

Sorry if this sounded like complaining, there were (very) few points where I strongly disagree, but overall a good overview. I probably would've split it in at least 2 parts - e.g. for a CEO (overviews, less details, but more fields) and CTO level (technical stuff, with details).

USB flash drives is the term used in the US, right?

us-west - perhaps I should change it to don't use us-east-1, since it fails much more often and is more crowded.

I'll rephrase the git and 2fa.

Endpoint Security - you gotta have it. I understand the natural objections, but there is no certification that doesn't ask about it. There are the more expensive ones like cyberreason or carbonblack.

I need to research more the domains issue. I suppose it's more prevalent in Israel since some devops in Israel worked for gaming (gambling) companies where they definitely use multiple domains for multiple purposes. But I think the main reason is allowing devs more management access to internal subdomains and disallowing management access to the API endpoint domains that customers use, to reduce attack surface.

Thanks for your comments. Keep them coming

hi. Here is my attempt to clarify the domains section. Could you please comment on PR https://github.com/forter/security-101-for-saas-startups/pul... ?

SPF and DKIM can be applied just fine to subdomains, I don't understand the suggestions made for email, yet there are good reasons to have a few extra domains, none which are actually mentioned: accidental cookie leakage and redundancy being obvious ones. The implication made for the API domain was that it should not be protected by SPF and DKIM

I stopped reading there

My understanding was that SPF and DKIM are only for sending emails.

I need to rearrange that paragraph and add the 2 other reasons you mentioned, and you are right that outgoing emails are better sent from subdomains.

I do wonder though if a spam filter blocks x.d.com would it also block emails from d.com?

hi. Here is my attempt to clarify this section. Could you please comment on PR https://github.com/forter/security-101-for-saas-startups/pul... ?

I would advise against Google Drive for document sharing. Recently I tried to share a trial build of an application (an exe I built) with a client. I zipped everything up and created a share link. Google auto-flagged it as a terms of service violation and blocked the file. No way of getting round it, and no way Google will bother to remedy the situation in time.

There's also OneDrive for business which seems to work well for sharing, though syncing options are totally broken. There's no way to selectively sync a share folder, so either you have your entire filesystem downloaded or you go online to get files. That sucks when your backup is terabytes of data.

I ended up sending a Dropbox link instead. So far it seems to be more or less foolproof.

I am not sure that binaries are the use case for g-docs.

I would have used s3 for that.

For mass distribution, sure a solution like S3 is the way to go. However, this was more of a "The file is too large to email, I'll zip the build and send a shared link" occasion. Using S3 for that is a sledgehammer approach especially when you're working with people who aren't tech savvy.

The concern is that G-Drive (not Docs) seems to arbitrarily decide what you can and can't share using it. In this case, it was a binary and associated files. I was able to share an earlier build without problems. Was it a DLL I'd bundled? VCpp redistributable? Was there some pattern of bits in the code that bothered the file checker? I don't know what triggered the violation and probably never will.

> automation (for example a Jenkins task)

I think there's value in this, but I want to point out that often time Jenkins becomes a collector of tech/security debt itself. It has very high privileges, and often time accesses/changes are not properly auth & audited.

Are there any best practices you would recommend?

If any developer says code review is too "corporate", I would suggest that they need to try a different profession.

Code review is an industry practice these days, and that is a good thing. I would say even for POC / MVP development, CR is a must.

I might need to find a better example.... Do you have an example of a process that is not needed in the beginning, and needed one year down the road that is less obvious?

I think (good, thorough) documentation is probably a good example. Unnecessary early, when everything is in flux, but critical later, when there's too much for one person to know.

Yeah, docs is a good one.

Starting out a lot of people dump info in a wiki, but as they get bigger, proper docs (with actual doc writers) is a must.

Original Author here. If you have questions or comments I would love hearing them.

The biggest challenges are always internal/privileged access and policy/privilege, DR(ecovery|esponse), and maintenance/configuration management. You've covered these well.

Couple notes: * VPNs are not panacea. My own experience is that ssh and significant key management (no password or emergency password only) is a more scalable strategy than relying solely on VPNs for small business. The whole default port thing with ssh is a no-brainer (don't do it + restrictive configurations of ssh for port forwarding and tunneling) as are the standard approaches to dealing with abuse of any service (fail2ban, etc...) Add to this a design which sandboxes ssh access based on time/privilege and only allows escape|access to critical resources via another mechanism. * WAFs are great but are extremely high maintenance and can be a productivity and production malf and bottleneck waiting to happen. * DDOS mitigation: https://www.akamai.com/us/en/solutions/products/cloud-securi... or the like.

SSH does not cover all use cases.

One example if you have an internal web service, how would you restrict access only to employees (without having it open to the internet?). SSO is not enough since you want the ports closed to non employees.

Another example is accessing a database that is not configured with SSL. You don't want your info travelling in plaintext on the internet.

I work remotely. SSH is exactly what I use to access our internal-only (web) services.

Do you use ssh as a socks proxy?

Yes. Typically:

  $ ssh -D 8888 <bastion host>

I have a Firefox add-on that makes it very easy to switch the proxy settings on and off.

And do you find that non-techies can also handle this? Also, I think this won't cover DNS changes that a vpn client does

ssh covers both of these cases.

There is another issue, that US citizens ussually do not encounter. When you setup a VPN on amazon, for example, you would like only some of the traffic (intranet) to go through that VPN (or SSH socks proxy). The rest of the traffic should go directly to the internet. The reason being is that the roundtrip is too costly.

I am not sure configuring these settings are trivial, and VPN clients provide that out-of-the-box.

Same question. Do you refer to using SSH and socks proxy. If so, is that a viable solution, in your experience, with less techy employees?

Less techy employees shouldn't be on any private/internal networks. Just give them an HTTPS web panel to work on authenticated by the SSO system.

SSO is not enough. In secure systems you are ussually required to provide both network access, and applicative access restrictions

It would be utterly transparent. Please don't be ignorant.

Some of it seems like overkill. Now that Google Cloud Shell is a thing, the correct answer for small teams of people who are not security engineers is usually just "chromebook".

As a founder of a company I would gladly buy chromebooks for all employees if it would solve my security problems. Sadly, I don't think today there's one solution that addresses everyone's needs, balancing dev requirements with security (and I don't think here will be one so soon):

1. We are a company that develops for iOS, so we have Apple computers and laptops... Nothing to be done about that. 2. We are on AWS, switching to Google Cloud is definitely not for everyone, definitely not just for this feature. 3. Even if we had not been developing for iOS, some developers really value working on a MacBook, and in a highly competitive recruiting market, that's a factor, and not an insignificant one.

I run 100% in AWS too and still use the (free) Google Cloud Shell for doing dev and orchestration and running terraform and docker-machine and whatnot.

Do you mean that you use it as bastion host?

I'm not familiar with it. How many startups that you know actually use it? Was it released only recently?

Also, do you know of startups that use chrome books or toshiba zero client?

Also keep in mind that laptops are used by data scientists and management

Disabling email attachments from your email server is also a good idea.

Can it be done with hosted mail solutions like most startups use? (Gmail/office365)

I know you can do it with Google Apps. Have not tried with Office365.

After sleeping on it... I am not sure it would work with managers. They work with outside council on a day2day basis and they use attachments for that. I wonder why gmail hasn't made phishing attachments obsolete.

If you just blocked zip files, it would be a good start.

Gmail does block quite a few attachment types. Zips are tricky because they're a very common way to send a collection of photos or docs or similar.

> Open an email group and name it [email protected] and add a page on your website to report security incidents to this email

You know a company takes security seriously when they have a typo in the word "security".

It's on github and you can submit a pull request in not much more time than it took to snark here. (I submitted one for some of the other grammar/spelling issues in the file. [sorry for using the online editor-that authored a poor diff])

Typos happen all the time - I was going to suggest that it was a bit of an unfair comment. Then I opened up their website [0] and their strapline is "In fraud prevention Accuracy Matters"...

None the less it is a useful document for those not versed in the basics of opsec and there's likely more value in insightful comments on the content...

[0]:https://www.forter.com

Mmm. I'm sure our marketing would like to know why it feels strange. Would you care to state it even if it feels obvious to you?

accurate ˈakjʊrət/ adjective

1. (especially of information, measurements, or predictions) correct in all details; exact. "accurate information about the illness is essential" synonyms: correct, precise, exact, right, errorless, error-free,

A typo is the antithesis of this.

However, as I mentioned in my previous comment the content is of value and to find fault in the guise of typos is absurd.

Ahhh - now I get it. Well our marketing staff are mostly native English speakers. I'm not :)

Ha ha. That's my typo. I'll fix it. Thanks

Funny thing is I've seen this same typo (security spelled with a missing "c") first hand when reporting a security incident. What made it particularly bad was that it was a mailto:// link that was also spelled wrong so clicking it would send the email to the wrong address with no bounce reply (I'm guessing they had a catch all inbox rather than bouncing bad addresses).

Might want to throw in there a suggestion to generate a [email protected] GPG key and instructions to use it if the submitter feels it warrants it. Also, the usual note of not losing the private half of the GPG key so you don't look like an ass when someone emails you an encrypted security incident that you cannot decrypt!

Thanks. I will

Please comment on https://github.com/forter/security-101-for-saas-startups/pul...

> Remember that SSL encrypts network traffic, but does not supply authentication. SSL is also not a replacement for 2FA.

False and false.

Are you referring to something like SRP+DSS|RSA? Not widely supported but I've used it via gnutls as a custom auth proxy layer for various things. 1password uses something like this iirc.

A really simple TFA pattern with SSL enabling is requiring a signed client cert with additional directory services auth (or even basic auth).