Zero Trust Networks
crawshaw.io
crawshaw.io
With everyone looking at remote work, tons of people must be questioning their VPN strategy right now. I know we are.
I was going to complain that that's a close source product (as I don't want to use something closed source for my network access controls) but it looks like the code is on Github, just not linked in an obvious way from the website. https://github.com/tailscale/tailscale
Has anyone used this or checked out the code? I may give it a spin.
I guess right now you have to run these solutions inside of the same container you want to allow in the network, so have to build it apart of your image... unless maybe you had your own custom base image with the VPN software loaded and just pass in the auth cert info at runtime.
However tailscale has a polished UI it looks from the screenshots, maybe meant more for employees to use than using it for all the server to server stuff.
I've been playing around with an idea on and off I was planning to use some sorta tech like this but seems like stuff is improving. Like early this year Podman folks are going to adopt a API like Docker instead of Varlink. Varlink seems cool too but I guess not as many people wanted to support it and then no lib for every language or runtime like Node.js, etc.
Also even if your own private network, still recommended to encrypt and authenticate internal services talking to each others. but I guess it's like having multiple layers.
1. Zscaler ZPA - closed source but from a market leader
2. Palo Alto - subjective if true zero trust but if you already have PA...
3. Akamai - based on a SDP acquisition which had good tech - not sure what Akamai has done with it
4. NetFoundry - both open source and SaaS options
5. Nebula - strengths for east-west microservices. Open source from Slack.
6. Tailscale - listed above. New but open source.
7. Appgate - closed source but nice implementation of the use cases it targets.
8. Illumio - a more mature version of Nebula; also targeted at east-west.
9. Centrify - closed source but solid option for IAM focused use cases.
10. Perimeter81 - not familiar with it but is well regarded.
11. Cloudflare - relatively new solution but leverages their network nicely
12. Duo - certainly was a nice solution - not sure what Cisco has done with it.
13. ZeroTier - not familiar but adding per comments below
* Edits - added 11-13 per comments below in attempt to make this a more comprehensive list.
Also not everything on that list is the same. Some of those are app-level gateways, IAM infrastructure, etc. That's a bag of stuff for different use cases.
Some of that stuff is also cloud proxy based, not mesh based. Maybe some people don't care but I'm heavily biased toward peer-to-peer mesh. I find it offensively stupid for packets to travel 1000 miles to reach a system next to me or in the same city. Of course I guess everything has a use case. I might opt for a cloud proxy if the bandwidth were low, the users and/or customer were non-technical, and it was all web stuff.
now you know, nothing here is just coincidental, not even the timing the posts are submitted or the type of comments that get quickly upvoted or buried to derail the discussion in a certain direction or even the links injected in comments of popular threads to improve the SEO of some companies and projects. Every, again EVERY, WireGuard post over the past 2 months has instantly converted into a shilling party for this company that literally has no product to offer, its source-code is pre-alpha state yet the party is persistent for every thread, it seems that the owners have really powerful friends all over the place and that's why they're having free ride despite having no product. This recipe for having a popular startup name with no actual product has really worked very well in the easy times of 2014-2020. Let's see how things work out this time
We have generally been focusing on behind the scenes tech more than GUIs so far.
I am sure is kinda popular at r/datahoarder and related communities. May be you need to apply for a GSOC type project - so that academics start using it (will then later get used in corporate).
1. Security isn't an absolute.
2. Defense in depth.
PDR (protect, detect, respond) is a well regarded strategy, for good reason. All of these are easier when done centrally (cloud proxy based). Detect can be particularly difficult to do well in mesh. You probably find it offensively stupid because zerotier doesn't have a Detect component, nor integration for one, nor any kind of consideration for it at all.
Cloudflare Access is worth having on the list (and it's free right now [1]). It is a pretty flexible identity aware proxy, and ssh gateway. We use it internally for those two things for basically all of our infrastructure and internal applications.
If it works for you that's awesome, if not (or you have just general questions) I'd love to hear feedback about why not / what else you might be interested in. I work on our security team but work really closely with the access team, so would be happy to pass on feedback to them.
1 - https://blog.cloudflare.com/cloudflare-during-the-coronaviru...
ZeroTier is much easier to understand and I like it.
I'd advise Tailscale to rethink their pricing. I'm not averse to paid services at all, but it's pretty hard for me to justify hundreds of dollars a month for "VPN access management software", even to myself.
Tailscale, if you're listening and are not too drunk on the patio11 "charge more" "i know what i'm worth" kool-aid: I am smack bang in your target market. Small to medium company, appreciative of wireguard, very security conscious, time poor, happy to spend money to make my life easier - but your pricing is ludicrous for what is essentially a VPN config manager.
I am not paying USD$10/user/month for google login to a VPN. That's more than I pay for actual GSuite. I have to justify, broadly, what I spend. Can you put yourselves in my shoes?
I suggest charging $24.95/m for 1 admin user, with 50 non-admin users free. $50 for 3 admins, 99 for 10, and so on.
I have to say, disappointed in the author's understanding of zero trust. Microsegmentation and ZT are at odds with each other; one is not a progression to the other. Of course, he has that POV because "his salary depends on it". I rather wish he had coined a new term here: nanosegmentation perhaps.
Regardless of accuracy/understanding, tailscale is certainly interesting and perhaps a better (more practical) solution than others -- at small scale. So don't take my criticism as poo-pooing their interesting approach. Rather, I am not pleased with their furthering the widespread differing understandings of zero trust, in service to their own needs. Then again, I'm not a principal in a "zero trust" company, so who am I to say what is fair in love and war.
A good security and connectivity system provides both.
Before reading the paper, That beginning has hit me, That's a brilliant writing skill.
Everyone knows that's the ideal network, but in practice it takes a lot of resources, that's why people prioritize internet exposed things. I mean, outside of tech companies (even then..) Most companies don't even fix critical security vulns internally fast enough. Behold exemptions galore!
My problem is this term is used way beyond netwoking to mean so many different things. What the author describes is not what half security vendors think zero trust means.
I don't dislike the term because it's a jargon but because the ambiguity leaves too much room to turn it into another box people check to have a false sense of security.
Something like "AAA resource access" (Authentication,Authorization,Auditing is an very old networking concept from cisco land) might be a better term. You gotta be unambiguous so it's easier to say "No, you have not implemented that".
Removing or not deploying basic firewall controls to lock down traffic is ill advised. Tons of exposed s3 buckets and other assets keep showing that.
Zero Trust is correct strategy of course, but it doesn't mean you have to open up your network to the entire world- it's in addition to already established best practices. Better to continue those traditional practices and be more thorough via micro-segmenation for instance, and identity on top of it.
This leads to an outsized focus on the latest sexy vulnerabilities (e.g. CPU speculative execution vulnerabilities) and fetishes for things like firewalls. Meanwhile people type 'npm install kitchen-sink' with no worries.
In my own anecdotal but real world experience most breaches result from phishing, downloaded malware, phishing to get the user to download malware, and malware-assisted phishing, in no particular order. Firewalls do nothing for that.
I'll also add that once I'm on a traditional network, ripping through active directory is generally not difficult - my first ever live pentest went from privileged non-AD asset to domain admin within about 4 hours. My average time to compromise has come down significantly since then, too.
There's lots of bad/scam security focusing on logging and monitoring, weird antivirus products and securing the wrong things. The last network I compromised dropped an obscene amount of money on a SIEM product that couldn't detect nmap or PtH attacks, I achieved complete compromise with the same chain of attack as my first ever pentest because nobody had looked at the fundamentals of implementation/configuration security.
If I could list things that would actually secure traditional networks:
- Application Whitelisting (Binary executables, strong macro group policies, browser plugin whitelisting).
- Active Directory Hardening (See: ADSecurity, Microsoft AD Hardening Guidelines, ACSC Windows 10 Hardening Guidelines)
- Regular Patching and reliance on Microsoft Products (they're actually pretty good!)
Dunno if you'd consider these 'zero trust', but unless you've covered the fundamentals nobody is going to waste time figuring out how to abuse your network with speculative execution or drop a huge amount of budget to develop a perimeter breaching RCE 0day. Especially when in most cases sending shitware.docx.exe to a sales staff member (who is almost always going to run whatever you send them if there's a bonus incentive) will suffice.
> Client machines WITH credentials has to be made untrusted.
Network segregation is better if you truly care about security and costs in productivity. I think you'll find higher end environments have a 'trusted box' and a 'development box' which physically sit side-by-side on different networks.
I think the difference in perspective is that I only really need to work in very narrow an well defined interface to systems that can be hacked, so my view of what the attack surface is affacted by that, I do not care about. For me as long as revealing my password to my client is fine I'm fine. My client can be full of malware without affecting security severly.
Clean room; "leave everything connected on the outside", and variants of that is REALLY ineffective. I've measured that the waste from that, back then we spent alot of time classifing what software had to be developed in such an environment. You do not want to work that way.
Firewalling AD networks, for instance, really won't help if the administrative security model is flawed (network admins using privileged account to maintain endpoints, privileged local administrative/maintenance credentials being reused on critical infrastructure, etc). The communication protocols for administration and general use are iirc pretty much require bidirectional traffic to work.
If you don't trust the host you develop on then everything produced on that host must be audited by a trusted host. Maybe that works in environments where cost is not an issue, but I would be somewhat skeptical of any environment which attempts that without the appropriate resources. It also doesn't help in situations where source code disclosure is an issue (eg a dev posting too much to pastebin/stackoverflow/inadvertently searching google for paste buffer full of data etc).
sounds like a fantastic plot for an anime. i can even see firewall san in my head :)
seriously though, maybe phishing and malware are common because firewalls are working?
Unless you are running vulnerable unpatched or unprotected services, attacking people is usually easier than attacking systems.
am i saying something different in my comment?
For example, if you have a 'trusted' network, a successful phishing attack gets you access to that network. If you have a 'zero trust' network, that attack only gets you access to the compromised user.
Zero Trust includes heavily leverageing attack surface limitation to prevent lateral movement. This means even if an attacker has stolen passwords, cookies or whatever single factor token that is needed to move laterally, they can't - because no connectivity.
My own opinion is: Secure. The. Endpoint.
If your devices, OSes, etc. are not secure then your systems are not secure. A firewall will not save an insecure system, and firewalls and netsec in general gets far too much attention. That attention should be focused on OS-level and application level security.
Company laptops often have RDP or SSH open - and newly added software might expose a remote endpoint in future (or a 0 day, like EternalBlue).
And here it comes: then an employee works from home or a coffeeshop and anyone there can attack and try to login! Locking down these things is critical to securing the endpoint.
Security isn't the only thing in the optimization equation; endpoint security is only useful — and humane — to a point.
Would firewall rules help alleviate that though? I can only speak for GCS (GCP's s3 equivalent), but firewall rules don't apply to GCS buckets.
Like a sibling commentator said, I would like to know more instances of companies getting breached specifically for adopting a zero trust networking philosophy.
So they in spirit do Zero Trust, but end up without basic security controls nor full fledged micro segmentation and identity.
If you work at a startup and experience exponential growth, you know that your internal production network likely has no authentication - this is unfortunately not uncommon and can be dangerous.
What old school security controls prevent, are the script kiddie attacks (ooops, that database or Elastic Search cluster exposed on Internet) and random automation attacks - which there are plenty of examples.
Then they're not doing zero trust, they're doing minimal access controls, which is rather the opposite and the problem.
Like we use GSuites and have MFA, all our problems are solved because we now are BeyondCorp. That's marketing speak.
Plenty of companies paid dearly for trusting every device that merely needed internet access.
Nowadays U2F based 2fa authentication and need to know based authorization are usually superior.
I think GP is implying that IT departments are taking away that [wrong] message. Just look at the proliferation of zero trust companies that do no such thing.
Is there a list I can look at? Who are you referring to?
> precise, narrowly-understood terms
ha! if only zero trust were precise! By narrowly-understood, the author means "well understood by those that speak jargon, but impenetrable to outsiders". In this case though, there's a nice irony in that statement.