Traditional network access controls work by assuming that something is trustworthy based on some other factor - for example, if a computer is on your office network, it's trustworthy because only trustworthy people should be able to gain physical access to plug something in. If you restrict access to your services to requests coming from trusted networks, then you can assert that it's coming from a trusted device.
Of course, this isn't necessarily true. A machine on your office network may be compromised. An attacker may obtain valid VPN credentials. Someone could leave a hostile device plugged in under a desk in a meeting room. Trust is being placed in devices that may not be trustworthy.
A Zero Trust Architecture (ZTA) is one where a device is granted no inherent trust. Instead, each access to a service is validated against some policy - if the policy is satisfied, the access is permitted. A typical implementation involves granting each device some sort of cryptographic identity (typically a TLS client certificate) and placing the protected services behind a proxy. The proxy verifies the device identity, queries another service to obtain the current device state (we'll come back to that in a moment), compares the state against a policy and either pass the request through to the service or reject it. Different services can have different policies (eg, you probably want a lax policy around whatever's hosting the documentation for how to fix your system if it's being refused access to something for being in the wrong state), and if you want you can also tie it to proof of user identity in some way.
From a user perspective, this is entirely transparent. The proxy is made available on the public internet, DNS for the services points to the proxy, and every time your users try to access the service they hit the proxy instead and (if everything's ok) gain access to it no matter which network they're on. There's no need to connect to a VPN first, and there's no worries about accidentally leaking information over the public internet instead of over a secure link.
It's also notable that traditional solutions tend to be all-or-nothing. If I have some services that are more sensitive than others, the only way I can really enforce this is by having multiple different VPNs and only granting access to sensitive services from specific VPNs. This obviously risks combinatorial explosion once I have more than a couple of policies, and it's a terrible user experience.
Overall, ZTA approaches provide more security and an improved user experience. So why are we still using VPNs? Primarily because this is all extremely difficult. Let's take a look at an extremely recent scenario. A device used by customer support technicians was compromised. The vendor in question has a solution that can tie authentication decisions to whether or not a device has a cryptographic identity. If this was in use, and if the cryptographic identity was tied to the device hardware (eg, by being generated in a TPM), the attacker would not simply be able to obtain the user credentials and log in from their own device. This is good - if the attacker wanted to maintain access to the service, they needed to stay on the device in question. This increases the probability of the monitoring tooling on the compromised device noticing them.
Unfortunately, the attacker simply disabled the monitoring tooling on the compromised device. If device state was being verified on each access then this would be noticed before too long - the last data received from the device would be flagged as too old, and the requests would no longer satisfy any reasonable access control policy. Instead, the device was assumed to be trustworthy simply because it could demonstrate its identity. There's an important point here: just because a device belongs to you doesn't mean it's a trustworthy device.
So, if ZTA approaches are so powerful and user-friendly, why aren't we all using one? There's a few problems, but the single biggest is that there's no standardised way to verify device state in any meaningful way. Remote Attestation can both prove device identity and the device boot state, but the only product on the market that does much with this is Microsoft's
Device Health Attestation. DHA doesn't solve the broader problem of also reporting runtime state - it may be able to verify that endpoint monitoring was launched, but it doesn't make assertions about whether it's still running. Right now, people are left trying to scrape this information from whatever tooling they're running. The absence of any standardised approach to this problem means anyone who wants to deploy a strong ZTA has to integrate with whatever tooling they're already running, and that then increases the cost of migrating to any other tooling later.
But even device identity is hard! Knowing whether a machine should be given a certificate or not depends on knowing whether or not you own it, and inventory control is a surprisingly difficult problem in a lot of environments. It's not even just a matter of whether a machine should be given a certificate in the first place - if a machine is reported as lost or stolen, its trust should be revoked. Your inventory system needs to tie into your device state store in order to ensure that your proxies drop access.
And, worse, all of this depends on you being able to put stuff behind a proxy in the first place! If you're using third-party hosted services, that's a problem. In the absence of a proxy, trust decisions are probably made at login time. It's possible to tie user auth decisions to device identity and state (eg, a self-hosted SAML endpoint could do that before passing through to the actual ID provider), but that's still going to end up providing a bearer token of some sort that can potentially be exfiltrated, and will continue to be trusted even if the device state becomes invalid.
ZTA doesn't solve all problems, and there isn't a clear path to it doing so without significantly greater industry support. But a complete ZTA solution is significantly more powerful than a partial one. Verifying device identity is a step on the path to ZTA, but in the absence of device state verification it's only a step.
comments
After going to an incredible Arch Enemy / Behemoth / Napalm Death / Unto
Others concert a few weeks ago, I decided I wanted to go to more
concerts.
I like music, and I really enjoy concerts. Sadly, I often miss great
performances because no one told me about it, or my local newspaper didn't cover
the event enough in advance for me to get tickets.
Some online services lets you sync your Spotify account to notify you when a
new concert is announced, but I don't use Spotify. As a music geek, I have a
local music collection and if I need to stream it, I have a supysonic
server.
Introducing metalfinder, a cli tool to find concerts using your local music
collection! At the moment, it scans your music collection, creates a list of
artists and queries Bandsintown for concerts in your town. Multiple output
formats are supported, but I mainly use the ATOM one, as I'm a heavy feed
reader user.
The current metalfinder version (
Finally, TIL, what can all be the reason for systemd services to hang indefinitely. The internet is flooded with numerous reports on this topic but no clear answers. So no more uselessly marked workarounds like: 
TL;DR: firmware support in Debian sucks, and we need to change
this. See the "My preference, and rationale" Section below.
In my opinion, the way we deal with (non-free) firmware in Debian is a
mess, and this is hurting many of our users daily. For a long time
we've been pretending that supporting and including (non-free)
firmware on Debian systems is not necessary. We don't want to have
to provide (non-free) firmware to our users, and in an ideal world we
wouldn't need to. However, it's very clearly no longer a sensible path
when trying to support lots of common current hardware.
Background - why has (non-free) firmware become an issue?
Firmware is the low-level software that's designed to make
hardware devices work. Firmware is tightly coupled to the hardware,
exposing its features, providing higher-level functionality and
interfaces for other software to use. For a variety of reasons, it's
typically not Free Software.
For Debian's purposes, we typically separate firmware from
software by considering where the code executes (does it run on a
separate processor? Is it visible to the host OS?) but it can be
difficult to define a single reliable dividing line here. Consider the
Intel/AMD CPU microcode packages, or the U-Boot firmware packages as
examples.
In times past, all necessary firmware would normally be included
directly in devices / expansion cards by their vendors. Over time,
however, it has become more and more attractive (and therefore more
common) for device manufacturers to not include complete firmware
on all devices. Instead, some devices just embed a very simple set
of firmware that allows for upload of a more complete firmware "blob"
into memory. Device drivers are then expected to provide that blob
during device initialisation.
There are a couple of key drivers for this change:
This post was originally published in the 
I wanted to understand how kids between 10 and 18 conceive the internet.
Surely, we have seen a generation that we call digital natives grow up with
the internet. Now, there is a younger generation who grows up with pervasive
technology, such as smartphones, smart watches, virtual assistants and so on.
And only a few of them have parents who work in IT or engineering
The youngest respondent, a 9 year old girl, drew a screen with lots of people
around it and the words film, series, network, video , as well as a play
icon. She said that she mostly uses the internet to watch movies. She was the
only one who used a shared tablet and smartphone that belonged to her family,
not to herself. And she would explain the net like this to an alien:
A 10 year old boy represented the internet by recalling user interface
elements he sees every day in his drawing: a magnifying glass (search
engine), a play icon (video streaming), speech bubbles (instant
messaging). He would explain the internet like this to an alien:
A 12 year old girl imagines the internet like a second, intangible, planet
where Google, Wikipedia, Facebook, Ebay, or H&M are continents that one enters
into.
A 15 year old boy knew that his family s devices are connected to a home router
(Freebox is a router from the French ISP Free) but lacked an imagination of the
rest of the internet s functioning. When I asked him about what would be behind
the router, on the other side, he said what s behind is like a black hole to
him. However, he was the only interviewee who did actually draw cables, wifi
waves, a router, and the local network. His drawing is even extremely precise,
it just lacks the cable connecting the router to the rest of the internet.
A 17 year old girl would explain the internet to an alien as follows: