1. 7
  1. 7

    I try to avoid these terms entirely and instead focus on three properties:

    Confidentiality: what entities are able to access data? How can an attacker exfiltrate data?

    Integrity: what entities can modify the data? How can an attacker corrupt it? What are the implications of such corruption and can they be detected?

    Availability: what needs to be working for this system to work? How can an attacker break it? What are the consequences of it breaking?

    The main thing that I’ve learned over the last couple of years is that integrity is often more important than confidentiality (in part because it’s very hard to guarantee confidentiality in the presence of an attacker who can corrupt data). There are a lot of cases where it’s fine for a cloud provider to see at least part of your workload (for example, that your running a particular program, and even the plaintext of your network traffic if you’re serving public info) but it would be very bad if they can tamper with it. Most recently, I’ve been working on an embedded platform where availability properties are important to me for the first time (in a cloud scenario, you trust the cloud for availability, you want to not trust them for confidentiality or integrity) because they can directly impact safety (if your car’s brakes or your pacemaker stop working, that’s probably worse than any confidentiality violation and worse than a lot of integrity violations).