An Approach to Measuring a System's Attack Surface

Abstract

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. Practical software security measurements and metrics are critical to the improvement of software security. We propose a metric to determine whether one software system is more secure than another similar system with respect to their attack surface. We use a system's attack surface measurement as an indicator of the system's security; the larger the attack surface, the more insecure the system. We measure a system's attack surface in terms of three kinds of resources used in attacks on the system: methods, channels, and data. We demonstrate the use of our attack surface metric by measuring the attack surfaces of two open source IMAP servers and two FTP daemons. We validated the attack surface metric by conducting an expert user survey and by performing statistical analysis of Microsoft Security Bulletins. Our metric can be used as a tool by software developers in the software development process and by software consumers in their decision making process. AbstractPractical software security measurements and metrics are critical to the improvement of software security. We propose a metric to determine whether one software system is more secure than another similar system with respect to their attack surface. We use a system's attack surface measurement as an indicator of the system's security; the larger the attack surface, the more insecure the system. We measure a system's attack surface in terms of three kinds of resources used in attacks on the system: methods, channels, and data. We demonstrate the use of our attack surface metric by measuring the attack surfaces of two open source IMAP servers and two FTP daemons. We validated the attack surface metric by conducting an expert user survey and by performing statistical analysis of Microsoft Security Bulletins. Our metric can be used as a tool by software developers in the software development process and by software consumers in their decision making process.

A Hierarchical Security Assessment Model for Object-Oriented Programs

“…Another is Alhazmi and Ray's approach which defines the security of a program based on its vulnerability density [8]. To be effective, this technique [2]. However, none of these approaches directly consider data-flow security of a program based on its design, as we do.…”

“…These include metrics which assess security at the abstract system architecture level [2], at the design phase [3] [4] and at the low level of program code [5]. However, none of this work to date is capable of measuring the overall security of a given program with respect to information flow.…”

An Assessment Model for Security-Critical Enterprise Systems

“…It is based on the set of possible resources which an attacker could use to attack the system [14], including methods, data and channels [14]. A method is described by Manadhata et al as a system entity which could send data (exit point) or receive data (entry point) [6]. Data in their approach is any entity which is visible in the current system such as files, cookies and database records [6].…”

Report: Measuring the Attack Surfaces of Enterprise Software

“…Manadhata and Wing's parameter sensitivity analysis suggests that the difference between the numeric values assigned to successive damage potential levels should be in the range of 3-14 [8]. Hence we chose the midpoint, 8.5, of the range as the difference.…”

“…First, we plan to extend the tool to measure the attack surfaces of software implemented in other languages such as JavaScript. Second, Manadhata and Wing performed three empirical studies to validate the abstract measurement method and the measurement results of systems implemented in C [8]. A possible direction of future research is to explore validation ideas in the context of SAP business applications.…”