←back to thread

656 points EthanHeilman | 4 comments | | HN request time: 1.202s | source
1. mikewarot ◴[] No.30106322[source]
Does any of this protect against a zero day exploit running in the client device?
replies(2): >>30107683 #>>30110452 #
2. wmf ◴[] No.30107683[source]
No, but once the exploit is discovered they could use client posture information to prevent unpatched clients from logging on.
replies(1): >>30108487 #
3. EthanHeilman ◴[] No.30108487[source]
It reduces your window of exposure.

For instance the zero-trust system we are building at bastion-zero uses ephemeral ECDSA key pairs attested by tokens that expire.

+ When the user logs out these key pairs and tokens are deleted. Ideally tokens should be revoked as well. If an attacker installs an implant on the user's endhost and the user is not logged in the attacker doesn't get any access because there is no keys/tokens to steal. If the implant/attack is discovered prior to the user logging the device can be reset and the attacker doesn't get any access.

+ If the attacker installs an implant on the user's endhost and the user is logged in. The attacker gets the key pair and tokens. If the attacker attempts to exfil the key pair/tokens and use them from another host this may set off alarms. The attacker if they wish to be stealthy and maintain access must conduct the attack through that endhost (at least include they compromise additional systems). Once the tokens expire the attacker is locked out again.

+ If the attacker manages to watch the user login and generate the attestation to the key pair and good MFA is employed, e.g. U2F/FIDO. The attacker can not eternally get new key pairs since they can not read the secret from the MFA device.

+ As wmf suggests, monitoring helps a lot. Monitoring is extra powerful when can easily revoke the user's key pair without revoking the user. Say a user triggers an alarm, automatically revoke the key pair and see if they can reauth. If it is a stolen key pair the attacker might not be able get a new key pair issues if the actually user is offline. If you decide the device might be compromised you can disable access from that device and have user pick up a new laptop.

4. agar ◴[] No.30110452[source]
In a true Zero Trust model, every client device would have the minimum number of network permissions necessary to do its job - as would every other device. Every device could only connect to known good/known necessary endpoints over specific ports and protocols. All else would be blocked.[1]

If the client device were compromised with a zero day exploit, the blast radius would be substantially smaller, the difficulty of an attacker mapping a network for later exploit would be exponentially larger, and time to response would dramatically shrink.

[1] (This is particularly relevant for fixed-function IoT and Operational Technology devices. General computing devices need broader controls, but again - the minimum necessary for that user, in that business context, to do their job.)