Reducing the Attack Surface of a Software

- Gagandeep Singh, Dept of Computer Engg, NIT Kurukshetra and Sumit Goswami, Dte of MIST, DRDO, New Delhi

The concept of attack surface can be easily understood by taking the example of a fighter jet. If an enemy wants to attack the jet from the front, the area visible to it for the attack will be less. But if it attacks by taking the orthogonal view of the plane, the area exposed for attack by the enemy will be more. This exposed area of the plane is its attack surface. It is quite obvious that more the exposed part, the more will be the attack surface and easier it would be for the enemy to attack.

In the field of computing, attack surface of a system may include protocols, services, interfaces, inputs entered by users, the code processing those inputs, and even humans having access to vital information. The attack may be executed via a network. Measuring the attack surface of a system is a good indicator of its security.

Types of attack surfaces

Attack surfaces can be divided in three categories:

- Network Attack Surface

- Software Attack Surface

- Human Attack Surface

Network attack surfaces are involved when attacks are launched via networks. Such kind of attack surfaces involve open ports and sockets like TCP ports and UDP ports. These attack surfaces mainly include tunnels running inside networks. In tunneling, the packets that cannot be transferred through a network are put inside other transferable packets and are transported. On the destination side, the encapsulated packets are received and stripped to obtain the original data. These tunnels are very hard to identify since they appear to be like normal traffic on the network.

The software attack surface is the code and functionalities that are available to unauthenticated users. It is an important problem as the number of bugs and vulnerabilities found in the software are on a rise due to proficiency and skills gained by attackers and therefore, the number of successful attacks is increasing at an exponential rate.

The human attack surface is quite different from the other two attack surfaces since they are based on unauthenticated users. It may involve social engineering, unavailability of an employee due to change of job, retirement or death or keeping a new employee, as it is not clear how much trust can be placed upon him. Human attack surface may involve dishonest or unscrupulous employees stealing or destroying data.

Common methods for measuring software security

The usual methods that are employed to determine the security of a system are at code level and at system level:

Code Level: At code level, the number of bugs and errors found in the code are identified. But this is not a very good method to determine security as all bugs are given equal weightage whereas some bugs are easier to take advantage and exploit than others. Also, it may miss some bugs that are not yet found and those may get exploited.

System Level: There are many organizations such as CERT-In, MITRE and websites like Security Focus, Microsoft Security Bulletins etc that keep record of drawbacks and vulnerabilities of various systems. The number of times a system's name appears in these bulletins is counted in order to get an estimate of the system security level. But this also is not an ideal approach as it ignores specific system configurations that may increase the attack surface and lead to vulnerability, such as a scenario when the software is being run in system mode or if the patch is not installed, etc.

Attack surface as a new metric

The concept of attack surfaces to measure the security level of a product lies in between the code level and system level approaches. It is above the level of coding, thereby giving the bugs importance based on ease of exploitation but at the same time, it is below the level of system, and thus is able to identify specific system configurations. We can say that this approach is at the design level of the system.

Thus, instead of counting bugs in the code and reading the software vulnerability reports from the bulletins, we identify the locations of possibility of attack by an attacker which collectively form the attack surface of a system.

But an important point to note is that this new attack surface approach measures the system security in relative terms such as two versions of the same product and not as a metric which can give a particular value as a result of the system security measure.

Measuring the attack surface

The attack surface of a system is defined by actions that users are able to see and resources that are being accessed and modified by those actions. Therefore, to measure the attack surface of a system, the resources that are most likely to get attacked with respect to various possible system actions are identified. Then, a value of the level upto which an attack class is dangerous if exploited is estimated relative to other attack classes. Knowing these payoff values, we can choose some of the attack vectors over which we can discuss and compare the security (or insecurity) level of two or more software applications.

The measurement of the attack surface should best be done while the software is in the development cycle. As the software development takes place gradually, the attack surface of the software also changes. Now, at certain intervals during these development stages, the measurement of the attack surface can be done and compared with that of in the previous stages. The reasons for the increase of the attack surface can be questioned and discussed, and reduction of attack surface at that level is done if possible.

For better understanding, we can consider the example given in the table (ref: Michael Howard, “Mitigate security risks by minimizing the code you expose to untrusted users.”) for measuring the relative attack surface of a hypothetical software product during development stage with a gap of one month.

Reduction in attack surface

Our goal for reduction in attack surface can be accomplished by fulfilling the following tasks:

- Reduction of the volume of code that runs by itself.

- Reduction of the exposed code that can be accessed by unauthenticated and untrustworthy users.

- Eliminating the entry points that can be easily attacked.

- Reduction in damage done during the course of the attack.

An important point to keep in mind is that not all areas of the attack surface are affected equally. As a result, some attack vectors have more probability to get attacked with respect to others. It has also been proved that files having full access rights denoted by (rwxrwxrwx) are more open to attacks in comparison to files with restricted access rights. Symbolic links are more vulnerable as these are used as a medium for attacks. Services that run with system privileges are more likely to get attacked instead of other user privileges. Minimizing the use of various script engines such as Jscript, VBscript and ActiveX controls is a good attack surface reduction measure as these are quite frequently used as enablers for an attack.

A good practice in reducing the attack surface is to decrease the code running by default. Now, this reduction can be done by turning off features that are used very rarely, but keeping an option to enable them again easily if required. To reduce the code and functionalities for untrustworthy users, one can reduce the access of the network endpoints of the software applications to only those users that are present in local groups or subnets. Simply asking for authentication from users can also restrict the access possible from untrustworthy users, thereby, reducing the attack surface of the system. Reducing privileges for the execution of the code is also a good step.

Current scenario

Organizations give a good amount of time in testing of codes and improving their quality. But measurement and reduction of the attack surface of a software or application is also very important in determining how secure it is from outside attacks and in estimating if the latest version of the software is safer and hence better than the previous versions. A major reason for this is that determining and testing the attack surface of a software is quite difficult during its development as it requires the software to be fully functional to measure the effect of a tested attack whereas testing software for improvement of code quality is fairly easy.

Conclusion

Measurement of the attack surface to calculate the extent of security level of a system software is a better method than using the code and system level metrics. Using the attack surface reduction method prevents a software from threats and vulnerabilities that are not yet known and thus, help in preventing future attacks. The attack surface reduction strategy should be implemented during the process of formation of the software when it is going through various phases of designing, coding and testing. It should be given equal importance as is given to code quality improvement and optimization.