Enumeration of Entry Points and Exit Points

When people secure objects in the physical world, such as their home, they first secure obvious entry points like doors and windows for good reason. These points are where attackers will most commonly attempt to gain entry. Likewise, it is important for security testers to understand the entry points and how potentially malicious data can enter the software being tested . Some entry points are fairly easy to identify just by thinking about the application. For example, an application that accepts data through the user interface or uses a user-specified data file has a few fairly obvious entry points. However, many entry points are not obvious. Identifying all entry points is so important in security testing that we dedicate Chapter 3, Finding Entry Points, entirely to the topic.

In the physical world in addition to securing entry points, people attempt to secure exit points, such as trash cans. For example, sensitive information is often shredded before being discarded. Companies concerned that sensitive information might be appear in the trash restrict access to the trash receptacles by using locks and/or guards .

In an ideal world, you could test everything completely. However, this isn t possible: you can t test every single piece of software as thoroughly as you might like. You need to prioritize where you will spend your time testing. The DFD is extremely useful in helping you identify where to spend your time. You want to find the most accessible parts of the software ”the most obvious entry and exit points ”and use this data to make testing prioritization decisions. For this reason, you must remember to consider and identify the access levels required to hit the various points in the DFD. For example, if the target application listens on a socket (allowing remote computers to connect to it), you must know whether a certain access level is required for the application to accept the data from the socket. For example, an application that allows only administrators to send data after authentication (using Kerberos, Internet Protocol Security [IPSec], etc.) is less of a security testing priority than is application functionality that can be invoked by anonymous users. Anonymous users and administrators are at opposite ends of the spectrum, but most users, including authenticated users, should be considered potential threats.

Tip  

It is often a good idea to create a prioritized list of the features and functionalities that will be tested and to obtain general consensus from other testers and developers before the actual testing. This helps ensure the most important areas are tested and everyone understands where the security testing efforts are focused.

In the DFD in Figure 2-1, it is clear that anonymous users can send data to the product through a Hypertext Transfer Protocol (HTTP) request. This functionality is a high-priority item to test because the HTTP requests can be made by anyone on the Internet.

Tip  

Good security testers verify that the entry points in the threat model are accurate by testing against the product. They also consider omissions, or hidden entry points that weren t considered during design and threat modeling, because, often, how people think something works and how it actually does work differ . Chapter 3 discusses how to find entry points in software.