A tale of rules and their makers

Management had made the choice, there was no disputing it without risking his job, he had heard bad things about the new system, but resigned himself to making it work. So he started reading the documentation and signed up for the support forums. The tutorials showed how rules worked, how to make new ones, the configuration of the auto-update feature, and how to submit a rule to the pool. The system worked by freely sharing rules which helped, so at least he could get the help of his peers.

Soon he was making rules that worked, and after that he learned how to make them simple and elegant. He could make a rule that had very few side effects, and stopped the threat without much cost. The system was getting slower, but thanks to advances in technology, a new system would soon be installed which was more than twice as fast as the old one. The users were fairly happy with things, as it kept disruptions to a minimum.

Over time, he learned about the pros and cons of the other rule systems, and how they worked. He wasn't a big fan of his system, but felt the users of the others were a bit too smug in their claims that there systems were somehow much better. He knew the basics were the same, that it was just a matter of time before theirs had similar problems, and that they mistook temporary conditions as a permanent condition.

One day it occurred to him that there might be a better way to do things. A friend had joked that instead of making rules to stop threats, perhaps it would be better to have a list of things that were not threats. It stuck in the back of his mind, and the more he thought about it, the more sense it made. He tried to explain his new idea to his friends, but they thought it was silly, and it would make it way too difficult to manage things, and would make the users complain too much about things they couldn't do because they weren't in the list.

Eventually he convinced some friends to build a prototype system, it would watch what the user did, and build rules to allow those things, and had a new feature which denied everything else. The idea of denying everything was crazy, but it worked in this case. The prototype system was interesting, but he thought it should go further. He had an even bigger idea, the thought the prototype should become the standard way of doing things.

His friends and peers thought he was nuts! How could you possibly list all the things the user wanted to do? Why would the users, who were the source of profit, possibly allow his group do such an absurd thing. If the list of allowed things didn't have something they needed, they would have to stop work and tell his group and get it added to the list. Such a presumption of power was surely a foolish thing to do.

He was sure his idea was right, but it wouldn't work because of the politics of it. He then wondered what would happen if the users could add things to the list themselves? This would leave the users with a system that would allow them to do what they needed, but without the need to have his group always blocking threats. Such a system would leave his group with a lot more time to work on the other tasks they had to keep interrupting, he was sure it would be worth it, but how to convince his peers?



Well.... by writing this very story. The above is a description of an imaginary world in which firewalls lack the ability to include a default deny rule. This makes it necessary to enumerate every threat and create a rule to stop it, and to share the list of rules. In our world, firewalls do have this ability, and we (network administrators) make rules explicitly allowing each protocol and port connection from the internet to our servers.


The above is also a description of this world. This is the way we currently handle computer viruses. We subscribe to services which list rules to identify bad code fragments, and we have systems which block those fragments when they are found. The point of this story is to get you to consider the opposite... a system which trusts nothing, and lets the users explicitly choose what connections and resources a program should get.

It's called capability based security, CabSec for short.

Thank you for your time and attention.