Determining Attack Surface

Determining Attack Surface

People like numbers, especially numbers used to evaluate items. As humans, we seem to seek solace in comparative numbers. I've lost track of how many times I've been asked, How much more secure is A compared to B? Unfortunately, this king of comparison is often incredibly difficult, and this section does not seek to answer that question. Rather, it will help you determine how many items in an application can be attacked. The process is extremely simple:

  1. Determine root attack vectors.

  2. Determine bias for attack vectors.

  3. Count the biased vectors in the product.

The result of this process is what's called the relative attack surface quotient (RASQ). Let's look at the process in a little more detail.

Determine Root Attack Vectors

Applications are attacked in certain ways. For example, all operating systems are attacked through sockets, Windows PCs are attacked by virtue of weak ACLs, Linux and UNIX servers are attacked through setuid root applications, and database servers are attacked through stored procedures. You must determine how attackers will attack your application. This should come from you guessed it the threat model!

Determine Bias For Attack Vectors

Next you must determine how bad an attack could be through the attack vector. For example, sockets are highly attacked points in an operating system, but weak registry ACLs are less attacked and attacks through them generally have less of a security impact. The bias should reflect the badness of each attack vector.

Count the Biased Vectors in the Product

Finally, you must count the attack vectors in your application and apply the bias to each vector to arrive at the RASQ. Let's look at an example: Windows. For Windows, I decided to count the attack vectors described in Table 19-6.

Table 19-6. Attack Vectors in Windows

Vector

Bias

Vector

Bias

Open sockets

1.0

Active ISAPI filters

1.0

Open RPC endpoints

0.9

Dynamic Web pages

0.6

Open named pipes

0.8

Executable virtual directories

1.0

Services

0.4

Enabled accounts

0.7

Services running by default

0.8

Enabled accounts in admin group

0.9

Services running as SYSTEM

0.9

Null sessions to pipes and shares

0.9

Active Web handlers

1.0

Guest account enabled

0.9

Weak ACLs in FS

0.7

Weak ACLs in registry

0.4

Weak ACLs on shares

0.9

The result of comparing various versions of Windows by using this method is outlined in Figure 19-4.

You should be aware that you cannot use this method to compare different operating system types because each is attacked in different ways and has differing biases (but you can compare like operating systems). A comparison of, say, Linux and OS/400 is meaningless.

As a tester, you can use this method to determine whether your application has more points of attack than the previous version. A useful and recommended use of RASQ is to place a goal of reducing the RASQ of the version under development compared to the previous version. The developers can add as many new features as they like, so long as they still reduce the RASQ by, say, 5 percent.

figure 19-4 comparing the relative attack surface of different versions of windows.

Figure 19-4. Comparing the relative attack surface of different versions of Windows.

Finally, this method is somewhat like function point analysis for security. It's not foolproof, and it does not account for code quality. However, it is useful nonetheless.



Writing Secure Code
Writing Secure Code, Second Edition
ISBN: 0735617228
EAN: 2147483647
Year: 2001
Pages: 286

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net