Why is there no perfect security
Put one lock on the front door and you are safer. Put on two and you are safer still. What about ten? Certainly safer, but now you have to turn a key ten times every time you come home, and the locks cost ten times as much. The principles from last lesson, pushed all the way, run into moments like this too. Security has no end, and making things safer always makes them more inconvenient and more expensive. So the real question is not how to become perfect, but where to stop.
There is no perfect
In this area we have seen many defenses. We locked contents with encryption, checked with hashes that nothing changed, and proved who we are with passwords and a second step. So if we combine them all, do we become perfect?
Sadly, no. Any lock may still give way to enough time and effort, and flaws nobody knows about yet may be hiding inside. The bar that tries to push security up to 100 never quite reaches 100, no matter how hard you push.
Push security higher. The bar approaches 100 but never reaches it. You only get closer and closer to perfect.
Push and push again, and the end of the bar never reached 100. That is the first truth of security: perfect is not a place you can arrive at.
That is no reason to be disappointed. The moment you accept that there is no perfect, your questions get smarter. Instead of asking how to become perfect, you ask how safe is safe enough, and that enough always comes with a price. Next we look at what that price is.
Safer means less convenient
The reason we do not push the bar all the way, even though we could, is simple: the price gets too high. The longer and more complex a password, the safer it is, but the more tedious it is to type every time and the more often it gets forgotten. The more layers of verification you add, the safer it is, but the more steps a single login takes.
Raise security one notch and convenience drops one notch while cost rises one notch. The three are tied in one line and trade off against each other. Too much inconvenience can even make things less safe, because people start writing hard-to-remember passwords on notes stuck to the monitor, or quietly skipping tedious procedures.
Raise the security level one step at a time. The higher it goes, the more safety fills up, while convenience shrinks and cost grows.
Each time the level went up, the three bars moved together. When one side got better, another got worse. This is called a trade-off.
There is no free path to more safety. Safety is always paid for in convenience or cost. So simply cranking it to the maximum is not the answer. Too low is dangerous, and too high means nobody can use it. Then where should the bar sit? The answer depends on how you handle risk.
Not removing risk, but managing it
If there is no perfect, risk cannot be brought to 0 either. Is security a losing battle, then? Not at all. You just change how you think about it: instead of trying to remove risk, you manage it. Crossing the street, the risk is not 0, yet we look both ways and cross.
The size of a risk is measured by looking at two things together: how likely it is to happen, and how much harm it does if it happens. You block the risks that are big on both counts first, until they are small enough, and you live with the small risk that remains. That is the realistic goal of security.
Block the risks one by one, biggest first. The risk never reaches 0, but it is brought down to a small size you can accept.
Blocking the big risks first made the bar drop sharply, but it never went all the way to 0. And that is fine; that is the point. When the remaining risk is small enough, you decide to accept it.
There are other ways to handle risk, too. You can avoid it: if you never collect information you do not need, it can never leak. You can pass it to someone else: insurance is one way to do that. Choosing among reducing, avoiding, transferring, and accepting is called risk management. So is an acceptable size the same for everyone?
The right balance for the situation
What counts as acceptable risk differs from situation to situation. If a notepad with today's lunch order leaks, it is a little embarrassing but no big deal, so a heavy lock would be overkill. If a bank vault leaks, on the other hand, it is a disaster, so you accept the inconvenience and make the lock thick.
The weight of what you are protecting sets the balance point. So when deciding on security, you first ask: what are we protecting, from whom, and how much would it hurt to lose it? The more precious it is, the more the bar moves toward safety; the lighter it is, the more it moves toward convenience. There is not one right answer; it differs with each situation.
Pick each of the two situations. The balance point shifts toward convenience for the light notepad and toward safety for the heavy bank vault.
The same lock did not suit both situations. A light lock suited the notepad, and a thick lock suited the bank vault. Good security is not the strongest security; it is the security that fits the situation.
And that balance point is not set once and done. As new attacks appear and the things you protect grow, the size of the risks changes too, so you need to weigh them again from time to time and keep up with updates. An eye that chooses balance, and chooses again, instead of chasing perfection: that is the way of seeing security this lesson teaches.
The road so far
Put this lesson together and it goes like this. There is no perfect security. Raising safety lowers convenience and raises cost. So instead of trying to bring risk to 0, you manage it by looking at likelihood and harm. You look at what to protect and how much, choose a balance point, and choose again when things change.
This is the last lesson of the security area, and a good place to look back at all eight Cogito areas we have passed through. Finally, let's retrace those eight paths together.
Tap the eight areas in order to look back over all of Cogito: structure, programming, operating systems, algorithms, networks, data, AI, and security.
We have touched all eight paths. In structure we saw the skeleton of a computer, and in programming we learned how to write instructions. We saw the operating system coordinate all of it, and in algorithms we built the skill of solving problems. Through networks we connected with the world, and with data we remembered and handled information. In AI we met machines that learn on their own, and in security we learned how to protect all of it in balance.
This journey was never about memorizing answers. It was about building the eye that sees the world through intuition and sets up its own formulas. Thank you for coming this far together. Now, with that eye, you can walk your own next road.