
Security 101 for SaaS startups - dpaluy
https://github.com/forter/security-101-for-saas-startups
======
cyberferret
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.

------
nkkollaw
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

~~~
mi100hael
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.

~~~
metafunctor
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](https://support.apple.com/en-
us/HT204837)

------
simplehuman
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

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

~~~
thedevil
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.

~~~
itaifrenkel
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

~~~
the_common_man
Slack is not free of the problem whatsoever:

[https://arstechnica.com/security/2016/04/hacking-slack-
accou...](https://arstechnica.com/security/2016/04/hacking-slack-accounts-as-
easy-as-searching-github/)

[http://www.businessinsider.com/slacks-security-breach-may-
be...](http://www.businessinsider.com/slacks-security-breach-may-be-worse-
than-its-letting-on-2015-3)

[http://www.networkworld.com/article/3123727/collaboration/th...](http://www.networkworld.com/article/3123727/collaboration/the-
next-target-for-phishing-and-fraud-chatops.html)

~~~
daenney
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

------
wink
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).

~~~
itaifrenkel
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

~~~
itaifrenkel
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...](https://github.com/forter/security-101-for-saas-
startups/pull/35) ?

------
_wmd
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

~~~
itaifrenkel
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?

------
joshvm
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.

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

I would have used s3 for that.

~~~
joshvm
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.

------
ecesena
> 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.

~~~
itaifrenkel
Are there any best practices you would recommend?

------
mugsie
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.

~~~
itaifrenkel
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?

~~~
l_t
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.

~~~
mugsie
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.

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

~~~
sneak
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".

~~~
eranid
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.

~~~
sneak
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.

~~~
itaifrenkel
Do you mean that you use it as bastion host?

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

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

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

~~~
itaifrenkel
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.

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

~~~
mi100hael
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.

------
koolba
> Open an email group and name it seurity@mycompany.com 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".

~~~
anotherturn
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](https://www.forter.com)

~~~
itaifrenkel
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?

~~~
anotherturn
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.

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

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

False and false.

~~~
jankedeen
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).

