css and more details

content/posts/qubes/index.md

@@ -75,7 +75,11 @@ Qubes OS includes Whonix by default (Qubes-Whonix) for when you want to force al
 >
 >Whonix virtual machines may be more leak-proof, however they are not amnesic, meaning data may be recovered from your storage device. By design, Tails is meant to completely reset itself after each reboot. Encrypted persistent storage can be configured to store some data between reboots. 
 
-In order to recover data from a Qubes OS system, an attacker would still need to successfully [bypass](https://www.notrace.how/threat-library/techniques/targeted-digital-surveillance/authentication-bypass.html) the [Full Disk Encryption](/glossary#full-disk-encryption-fde) (e.g. by seizing the computer when it is turned on, or cracking a weak password). The situation is the same with Tails if any data is saved to Persistent Storage or an encrypted USB - this saved data is no longer protected by anti-forensic features but by Full Disk Encryption. 
+If an adversary hacks your Tails system to get [initial access](https://attack.mitre.org/tactics/TA0001/), such as through [phishing](/posts/tails-best/#phishing-awareness), they need to achieve [privilege escalation](https://attack.mitre.org/tactics/TA0004/) in order to bypass Tor. The [most recent Tails audit](https://tails.net/news/audit_by_ROS/index.en.html) found several privilege escalation bugs. 
+
+If an adversary hacks your Qubes-Whonix system to get [initial access](https://attack.mitre.org/tactics/TA0001/), they need to achieve [lateral movement](https://attack.mitre.org/tactics/TA0008/) to the Whonix Gateway, and then achieve privilege escalation from there in order to bypass Tor.  
+
+In order to recover data from a Qubes OS system when it is turned off, an adversary would still need to successfully [bypass](https://www.notrace.how/threat-library/techniques/targeted-digital-surveillance/authentication-bypass.html) the [Full Disk Encryption](/glossary#full-disk-encryption-fde) (e.g. by seizing the computer when it is turned on, or cracking a weak password). In order to recover data from a Tails system when it is turned off, **the situation is the same if any data is saved to Persistent Storage or an encrypted USB** - this saved data is no longer protected by anti-forensic features but by Full Disk Encryption. 
 
 Our recommendation is to use Tails:
 
@@ -408,8 +412,8 @@ Qubes OS also applies appropriate software mitigation to this class of attacks a
 
 To address "future not-yet-identified vulnerabilities of this kind" on older hardware that no longer receives microcode updates, the operational security (OPSEC) suggestion is to limit the presence of secrets in memory that could lead to leaks. Each running qube uses memory, and a compromised qube could use such vulnerabilities to read and exfiltrate memory used by other qubes. Disposables are reset after they are shut down, so we can assume that their compromise would likely be temporary. Perform sensitive operations in qubes without networking, and shut down secure qubes when not in use. Make sure to always be aware of which qubes are running simultaneously - it is best to only have trusted qubes alongside each other. 
 
-* sys-usb: Disposable. Run only when needed, and shut down when finished. 
-* sys-net: Disposable. Run only when needed, and shut down when finished. Shut down when performing sensitive operations in other qubes, if possible. Restart before activities that require sys-net (i.e. email, ssh sessions, etc.).
+* sys-usb: Disposable. Run only when needed, and shut down when finished. Restart after using an untrusted USB device. 
+* sys-net: Disposable. Run only when needed, and shut down when finished. Shut down when performing sensitive operations in other qubes, if possible. Restart before compartmentalized activities that require high security.
 * [vault qube](#how-to-organize-your-qubes): 
 	* Instead of having only one vault qube that stores all files (as described above), you can compartmentalize by having different vault qubes dedicated to specific activities (i.e. `vault-personal`, `vault-project1`, etc.). This means that if a networked qube is compromised while working on project1, [intentional sniffing](https://www.qubes-os.org/doc/data-leaks/) will not have potential access to all files, but only to those files that are compartmentalized for project1.
 	* Configure KeePassXC to lock when it is unused: **Application Settings → Security → Timeouts**, enable **Lock databases after inactivity**. Configure [automatic clipboard wiping](https://www.qubes-os.org/doc/how-to-copy-and-paste-text/#automatic-clipboard-wiping), which is disabled by default. If you need a password when using an untrusted qube: