What Does this Risk Mean to Me?
Author: Peyton Engel
July 2007
This article is the second of two essays based on a talk from the 2007 OISC conference regarding the prioritization of vulnerability information. The first installment explored some reasons that the importance of a single vulnerability can vary drastically depending on where it occurs. This time we discuss methods for discovering hidden areas of importance and qualifying the impact of security flaws.
Let us consider three computers: Systems A, B, and C. One user “Peyton,” has an account on Systems A and B, and users the same password to log into each. A second user, Andy, has accounts with the same password on B and C. Suppose that there is a flaw in the security of A (say, for example, a missing patch, that allows an attacker to compromise the system). After the attacker compromises A, the next step is to crack the passwords there—once this is accomplished, Peyton’s account will allow the attacker access to B. If Peyton has root or administrative authority on B, the cracking process is repeated, and the attacker moves over to C, using Andy’s credentials. System C might have excellent security, and be administered by a different group than A, but A’s weaknesses expose C to risk. We call these relationships between systems “trust relationships” (also, “implied trusts” or “transitive trusts”), and we can visualize them as connections between systems.
FIGURE 1 - EXAMPLE ILLUSTRATION OF TRUST RELATIONSHIPS
Such illustrations are intuitive, but clumsy for representing large environments with many computers and users. Fortunately, we can represent these relationships mathematically, using a concept called an “adjacency matrix.” Constructing an adjacency matrix for our purposes is simple: we make a square grid with one column and one row for each system, and we put a 1 in the cells corresponding to a pair of systems for which a trust relationship exists.
Table 1 describes the trust relationships illustrated in Figure 1. If A is compromised, the attacker can get to B, so we place a 1 in the (A, B) cell. A compromise of B would allow an attacker to go to either A or C, and a compromise of C would yield access to B. This notation is well suited to large networks, and easy to represent programmatically, but its main advantage is that we can now apply useful mathematical concepts. We’ll discuss Table 2 in a moment. For now, note that the adjacency matrix describes only directly-next-door relationships (i.e., it depicts paths one hop in length); it is possible, however, to determine the complete set of all possible interconnections, regardless of length.
We’ll need some mathematical definitions for this— these terms will be familiar from arithmetic, but we’ll review them, to be safe:
- Identity: If we have some arbitrary mathematical operation (designated by ○), then the “identity element” (represented by I) for this operation satisfies the equation X ○ I = X. Thus, 1 is the identity element for numeric multiplication, and 0 is the identity element for addition. For the purposes of the matrix multiplication we’re planning, the Identity Matrix is the same shape as our adjacency matrix, but all elements are 0, except for the cells on the upper-left-to-lower-right diagonal, which are 1 (see Table 2).
- Inverse: For our same hypothetical mathematical operation, the inverse of an element X (represented by X-1) is the element that satisfies the equation X ○ X-1 = I. For numeric multiplication, the inverse of X is therefore 1/X; for addition, the inverse of X is –X. Computing a matrix inverse is a tedious process, but we can use computers to do the calculation for us when the need arises.
It turns out that if we multiply our adjacency matrix (which we’ll call M hereafter) by itself, we get paths of length two. This is a fundamental observation from graph theory—we won’t bother proving it here. Cubing the matrix gets us paths of length three. M + M2 + M3 gives us all paths of length one, two, or three. Some readers will remember the following geometric series from algebra:
There is an analogue for matrix math:
This equation allows us to perform a single calculation (i.e., calculate the inverse of the matrix formed by subtracting our adjacency matrix from the identity matrix), and produce the transitive closure of all trust relationships: essentially, the answer to the question, “if one given system is compromised, which other systems should also be considered compromised?” If an element in our resulting matrix is non-zero then that means there is some trust relationship, however circuitous, between the two systems it represents.
We can easily gather information about the trust relationships between systems: we simply log into each machine on our network as an administrator, dump the password database, and look for username-password pairs that recur between two systems: systems with shared account credentials are “adjacent.” For Windows systems, this is particularly easy—there’s no need to crack the passwords, and we can simply look for matches between encrypted strings in the password databases. Free, open source tools are available to identify users with administrative privileges, dump password databases, and even generate entity-relationship diagrams depicting the connections between systems and user accounts.
This view of our environment gives us insight into the implications of any given system’s compromise. We can spot ostensibly unimportant systems upon whose security our critical systems depend. We can also spot the main vectors (i.e., which user accounts) that would allow a compromise to spread quickly. Better still, the remediation path—changing our account management practices—is relatively straightforward, and doesn’t generally imply huge costs.
More importantly, we can begin to think about mitigating vulnerabilities we don’t yet know about. As mentioned in Part I of this essay, risk is typically expressed in dollars per year, as the product of factors including the Single Loss Expectancy for security incidents (dollars/incident) and their Annual Rate of Occurrence (incidents/year). Most often, we purchase security technology in order to address the rate of occurrence of some problem: the protective measure is supposed to render some bad thing impossible.
Deep down, though, we know that sooner or later bad things will happen, in spite of our defenses. By identifying and severing trust relationships, we’re applying the familiar “principle of least privilege,” reducing risk by minimizing the cost of those incidents that do occur, regardless of their cause. Ultimately, we’re able to make more effective security decisions, because we’ve gotten a better understanding of what a given vulnerability means to us.
For more information on Security please contact Berbee Information Networks, John Uchaker at (513) 677-4119 or visit www.berbee.com. Berbee, drawing on strategic partnerships with Cisco, IBM and Microsoft and the far-reaching experience of its hundreds of engineers, has assisted clients with a full range of technology solutions.
