Introduction to Security Dependencies

It comes as no real surprise to any system administrator that entities in a network depend on each other for their security. Users have their security guarded by the system administrator(s), member systems get security policies from the domain controllers, and so on. However, what most people do not think about is how this impacts the aggregate security of the network. In reality, what we end up with is a security dependency chain where no system is any more secure than the least-secure system that it depends on. This is a hard concept for us, as network protectors, to think about, because as IT providers, we are conditioned to make things work. Understanding security dependencies, by its very nature, involves understanding how to break things. But since the bad guys know how these dependencies work, and they almost always use them against us, it is very important that we do understand it.

Fundamentally, the concept is not too difficult. Consider, for instance, a laptop in a domain. Laptops are now outselling servers and desktops (http://deseretnews.com/dn/view/0,1249,510037647,00.html). This is logical, because they make our users more productive. Obviously, these laptops cannot be secure if the domain controllers are not secure, but is the reverse true? Can the domain controllers (DC) be secure even when the laptops are not? Let us hope so, because if not, we had all better plan on switching careers. We give them to the salespeople, who typically are not the most security conscious people in the business. They put all kinds of interesting and sensitive data on them, and then take them outside the perimeter, where they spend months surfing the Internet for who- knows -what on whatever network is available wherever they are. When they realize that something is wrong with their system, they do the absolutely natural thingconnect to the corporate network, where the help desk is! Now, which other systems would be compromised automatically because one of these laptops was compromised?

The same concept can be applied to servers. Take Microsoft's Internet- facing properties, for instance. They are usually run by the MSN group . Within the Microsoft data centers in the Puget Sound area, there are around 20,000 servers. That is a relatively sizeable data center. More interestingly, there are many different "properties," or services, within those data centers. For example, there is the MSN home page. If the servers providing the MSN home page were compromised, the home page would most likely be replaced with a page making disparaging comments about Bill Gates. Of course, the original home page would be back up very quickly, but it would still be big news. It would be all over the press how Microsoft has failed at Trustworthy Computing, yet again. (Each time there is even the hint of compromise of a Microsoft product or property, some pundit claims Trustworthy Computing is a failure.) Within a few weeks, it would mostly be forgotten, however.

Now consider some of the other properties hosted in the same data center, such as the MSN Bill Payer service. Using the Bill Payer service, you can pay bills to anyone in the world. You simply log in to the service and enter the person you want to pay and the amount. The system now deducts that amount of money from your bank account and cuts a check to the payee. That means that the Bill Payer service must store your bank account information. Now think about what would happen if that system were compromised. Microsoft would most likely get sued to the tune of about $60 billion, or whatever the current stockholder equity of the company happened to be. Those two systemsthe MSN home page and the MSN Bill Payer servicehave widely different security requirements. If you were to do a fault tree (see Chapter 9, "Network Threat Modeling") of the Bill Payer service, there should be no faults that imply jumping from the home page to the Bill Payer service. This brings us to two fundamental rules for network segmentation:

Less-sensitive systems may depend on more-sensitive systems.
More-sensitive systems must never depend on less-sensitive systems.

In comparison to the MSN Bill Payer service, the MSN home page is a less-sensitive system. If the MSN Bill Payer service were to get compromised, I frankly would not worry much about the home page for a while. By the same token, laptops, the less-sensitive systems, may (and do) depend on the domain controllers for their security. The reverse, however, must never be true. The MSN Bill Payer service must not be dependent for its security on the MSN home page, just like the domain controller must not have any dependencies on any laptops.

What does this mean for a real network? Well, the sad fact is that today, the hardest part of attacking a network is too often finding the next victim, not perpetrating the attack. Consider the real impact of dependencies. At Microsoft, we have about 250,000 systems in our corporate forest, give or take a few thousand. That is probably more than most environments, but some are even larger. Now, what is the chance that any one of those systems is insecure on any given day? If we assume, and this may be a very generous assumption indeed, that every one of those systems is secure (given some arbitrary definition of secure) 999 days out of 1,000, the chance that any single system is insecure today is 1/1,000. The chance that it is secure is 1-1/1,000 = 0.999. Three nines is not too bad for a mix of clients . Now, what if every single system on the network was dependent on every other system for its security? If that is the case the probability ( assuming these are independent probabilities) that the entire network is secure is 0.999^250,000 = 1.25 * 10 ⁸⁷ . That is as close to zero as we get, and it means you have a better chance of guessing my 46-character password on the first try than you have of ever securing a network of 250,000 systems where every system depends on every other system. We do not care for those odds. Clearly, we need to figure out how to mitigate dependencies.

Probability Primer

The probability that some statement is true is often expressed as a fraction. In the example of the network, where a system is insecure only 1 day out of 1,000, the probability that it is insecure on any given day is 1/1,000. The inverse probability, the probability that it is secure, is 1 minus the probability that it is insecure, or 0.999. Applying this to multiple systems is a bit harder. First, you need to know whether the probabilities are independent. If they are independent, the fact that one system is insecure does not have any bearing on the probability that another system is secure. In a dependent probability, if a system is secure, another system in the same network is more likely to be secure. If we can assume the probabilities are independent (which may not be entirely realistic), the probability that all systems are secure is the product of the individual probabilities of the systems being secure. For instance, if you have two systems, the probability, on any given day, that both of them are secure is 0.999*0.999 or 0.998001. Add a third system and the probability goes to 0.997002999. Add a few thousand systems, and the probability starts approaching zero. This highlights the reality, which is that it is almost impossible to control the security state of all systems in a network at all times.