I like the idea of canaries in documents, I think is a good point but obviously it only applies to certain types of data. Still a good idea.

Looking at OP, they seem a small shop, with a limited budget. Seriously the best recommendation I think is to use some kind of remote storage for data (works as long as the employee complies) and to make sure the access control is done in a decent way (reducing the blast of employee behaving maliciously). Anything else is probably out of reach for a small company without a security department.

Maybe I sounded too harsh, that’s just because in this post I have seen all kinds of comments who completely missed the point (IMHO) and suggested super complicated technical implementations that show how disconnected some people can be from real technical operations, despite the good tech skills.

DLP solutions are honestly a joke. 99% of the case they only cost you a fortune and prevent nothing. DLP is literally a corporate religion.

What you mentioned also makes sense if you are windows shop running AD. If you are not, setting it up to lock 1 workstation is insane.

Also, the moment the data gets put on the workstation you failed. Blocking USB is still a good idea, but does very little (network exfiltration is trivial, including with DLP solutions). So the idea to use remotely a machine is a decent control, and all efforts and resources should be put in place to prevent data leaving that machine. Obviously even this is imperfect, because if I can see the data on my screen I can take a picture and OCR it. So the effort needs to go in ensuring the data is accessed on a need basis.

Jamf doesn’t do anything for this problem, besides costing you a fortune in both license and maintenance/operation. Especially if you are not a Mac shop.

MDM at most can be used as a reactive tool to do something on the machine - as long as the one with the machine in their hand leaves the network connection on.

There are much cheaper solution to do that for 1 machine, and -as others correctly pointed out- the only solution (partial) here is not storing the data on a machine you don’t control. Period.

Yeah, that’s what I wrote too, but that is still a very fragile way. For once, you depend on a network connections, or in the local firewall not blocking you etc.

Reactive, on-demand ssh is something you can do for tech support, not for security imho.

Disk encryption is a control against lost or stolen device and malicious physical access (kinda). Storing the data elsewhere is more a control (or the basis for controls) against malicious insiders.

Your ability to SSH in the machine depends on the network connectivity. Knowing the IP does nothing if the SSH port is not forwarded by the router or if you don’t establish a reverse tunnel yourself with a public host. As a company you can do changes to the client device, but you can’t do them on the employee’s network (and they might not even be connected there). So the only option is to have the machine establish a reverse tunnel, and this removes even the need for dynamic DNS (which also might not work in certain ISPs).

The no-sudo is also easier said than done, that means you will need to assist every time the employee needs a new package installed, you need to set unattended upgrades and of course help with debugging should something break. Depending on the job type, this might be possible.

I still think this approach (lock laptop) is an old, ineffective approach (vs zero-trust + remote data).

Useful for standardized management of fleets, but requires personnel to maintain and configure it, but I don’t think it’s very effective (or feasible - I doubt they will even join the call for a 1-device contract) for what OP needs.

This is honestly an extremely expensive (in terms of skills, maintenance, chance of messing up) solution for a small shop that doesn’t mitigate at all the threats posed.

You said correctly, the employee has the final word on what happens to the data appearing on their screen. Especially in the case of client data (I.e., few and sensitive pieces of data), it might even be possible to take pictures of the screen (or type it manually) and all the time invested in (imperfect) solutions to restrict drives and network (essentially impossible unless you have a whitelist of IPs/URLs) goes out the window too.

To me it seems this problemi is simply approached from the wrong angle: once the data is on a machine you don’t trust, it’s gone. It’s not just the employee, it’s anybody who compromises that workstation or accesses it while left unlocked. The only approach to solving the issue OP is having is simply avoiding for the data to be stored on the machine in the first place, and making sure that the access is only for the data actually needed.

Data should be stored in the company-controlled infrastructure (be in cloud storage, object storage, a privileged-access workstation, etc.) and controls should be applied there (I.e., monitor for data transfers, network controls, etc.). This solves both the availability concerns (what if the laptop gets stolen, or breaks) and some of the security concerns. The employee will need to authenticate each time with a short-lived token to access the data, which means revoking access is also easy.

This still does not solve the fundamental problem: if the employee can see the data, they can take it. There is nothing that can be done about this, besides ensuring that the data is minimised and the employee has only access to what’s strictly needed.

For browser, there is a webapp that can be selfhosted. See here https://github.com/logseq/logseq/blob/master/docs/docker-web-app-guide.md

I think you need chromium browsers due to the API they use, but it should work.

Many encryption algorithms rely on the assumption that the factorizations of numbers in prime numbers has an exponential cost and not a polynomial cost (I.e. is a NP problem and not P, and we don’t know if P != NP although many would bet on it). Whether there are infinite prime numbers or not is really irrelevant in the context you are mentioning, because encryption relies on factorizing finite numbers of relatively fixed sizes.

The problem is that for big numbers like n=p*q (where p and q are both prime) it’s expensive to recover p and q given n.

Note that actually more modern ciphers don’t rely on this (like elliptic curve crypto).

Every point can be supported with an analogy bad enough

I can’t really make an exhaustive comparison. I think k3s was a little too opinionated for my taste, with lots of rancher logic in it (paths, ingress, etc.). K0s was a little more “bare”, and I had some trouble in the past with k3s with upgrading (encountered some error), while with k0s so far (about 2 years) I never had issues. k0s also has some ansible role that eases operations, I don’t know if now also k3s does. Either way, they are quite similar overall so if one is working for you, rest assured you are not missing out.

Yeah, but you don’t need anything besides the runtime with kubernetes. Podman is completely unnecessary since kubelet does the container orchestration based on Kubernetes control plane. Running podman is like running docker, unnecessary attack surface for an API that is not used by anybody (in Kubernetes).

I run k0s at home, FWIW, tried k3s too :)

Why would anybody use podman for k8s…containerd is the default for years.

Nftables is the modern iptables FYI. Linux firewall.

Sure! FYI, simplelogin can create aliases with prefix! I usually get service-{random 5 chars}@simplelogin.com, so you can still sort by folder using prefixes.

You should definitely be! I take backups every 6h for my self hosted vaultwarden (easier to manage and to backup, but not official, YMMV). You can also restore each backup automatically and have a “second service” you can run elsewhere (a standby basically), which will also ensure the backup works fine.

I have been running bit/vaultwarden now for I think 6 years, for my whole family and I have never needed to do anything, despite having had a few hiccups with the server.

Don’t take my word for it, but the clients (browser plugin, desktop app, mobile app) are designed to keep data locally I think. So the term cache might be misleading here because it suggests some temporary storage used just to save web requests, with a relatively quick expiration. In this case I think the plugin etc. can work potentially indefinitely without server - something to double-check, but I believe it’s the design.

Interesting! That’s very close to this blog post I read long time ago (unfortunately medium.com link)! Are you actually sending emails from those addresses? Like if you need to drop an email to your bank, do you use the banking one or your personal (or something else)?

Fwiw, I do something similar. I use a mix of domain aliases without address (e.g. made-up-on-the-fly@domain.com) and actual aliases. Since I have proton family (and the same when I used ultimate) I have unlimited hide-my-email aliases, so I have it integrated with my password manager, and I generate a random password and email for everything I sign up now. These though are receive-only addresses. In fact, with this technique I probably use 3-4 addresses in total, but I have probably 30 domain addresses that go to the catch-all one.

Spam on these addresses are basically non-existing and you can still create folders based on recipient without having a full address (e.g. bank1@domain.com, bank2@domain.com). You can make folder categorization based on recipient regex and this way you also have the “stop bothering me” option: if some email gets into the wrong hands, you can create a spam rule for that dedicated address. However, my approach is that all of these are used just to receive emails, to send I have just a handful of actual addresses or -if really needed- I can create on-the-fly an address from a catch-all one, send the email and then disable it again (so it doesn’t count towards the limit, but I still get inbound email to the catch-all).

Nice setup anyway!

Your requirements are totally fair tbh.

That said, I think you can use aliases for the use-case you have, you don’t need full addresses. Proton supports “+ aliases” as well, so name+service@domain works, and most importantly they support catch-all addresses if you have your own domain. I now use actual aliases (the ones from simplelogin), which I generate on the fly, but if you can use whatever@domain and it will be redirected to your configured address. You don’t even need to create this beforehand, so many times I was around and had to give an email address for some reason and I just made up an address on the fly. As long as you use your domain, the catch-all will get the email.

So the 10 addresses only include actual addresses, the ones you can write from. You can have as many as you want to receive emails (which is generally the use case for signing up to services, right?). Just a FYI in case tuta supports the same and you are making more effort than needed!

If XMPP were to replace emails, that would’ve been great

Who knows :) But XMPP also needed all kind of extensions to support even relatively old security measures.

Anyway, I still don’t trust Proton. Have a great day.

That’s fine, you can trust who you want, of course. The important thing is to have clear the risk model.