Security 101 for SaaS startups
github.com
github.com
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.
- 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
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.
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
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.
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.
> 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).
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
I stopped reading there
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?
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 would have used s3 for that.
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.
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.
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.
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.
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
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.
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.
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.
$ ssh -D 8888 <bastion host>
I am not sure configuring these settings are trivial, and VPN clients provide that out-of-the-box.
You know a company takes security seriously when they have a typo in the word "security".
Might want to throw in there a suggestion to generate a security@example.com 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!
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...
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.
False and false.
A really simple TFA pattern with SSL enabling is requiring a signed client cert with additional directory services auth (or even basic auth).