A Concept for Language–oriented Security Testing Philipp Zech, Michael Felderer, Matthias Farwick, and Ruth Breu Institute of Computer Science University of Innsbruck Austria Email: {philipp.zech, michael.felderer, matthias.farwick, ruth.breu}@uibk.ac.at Abstract—Today’s ongoing trend towards intense usage of web service based applications in daily business and everybody’s daily life poses new challenges for security testing. Additionally, such applications mostly not execute in their own runtime environment but instead are deployed in some data center, run alongside multiple other applications, and serve different purposes for sundry user domains with diverging security requirements. As a consequence, security testing also has to adapt to be able to meet the necessary requirements for each application in its domain and its specific security requirements. In addition, security testing needs to be feasible for both service providers and consumers. In our paper we identify drawbacks of existing security testing approaches and provide directions for meeting emerging challenges in future security testing approaches. We also introduce and describe the idea of language–oriented security testing, a novel testing approach building upon domain–specific languages and domain knowledge to meet future requirements in security testing. Index Terms—Security Testing, Domain–specific Language, Language–oriented Programming, Service–centric Systems I. I NTRODUCTION Since the beginning of the millennium IT faced tremendous changes in its usage. A first indicator of those changes was the early adoption of web services back in the early 1990s [1]. However, it lasted more than another decade until the mid 2000s, when the first Service Oriented Architectures (SOA) emerged and, more generally, large Service–centric Systems (ScS). The goal was to, on the one side, slenderize the desktop and, on the other side, to project complex business processes onto IT to enhance business itself [2]. This trend continued up to today, with its latest derivative, the evolution of cloud computing [3]. Yet, the application of cloud computing also emerged out of another opportunity of such ScS, the possibility of outsourcing complete IT landscapes (both, hardware as well as software) thereby saving money due to only paying for the effective usage of hard- and software. Taking a more distant look at such service–centric applica- tions reveals that their only actual commonality is their shared runtime environment, providing support for a vast amount of different services or applications. However, due to the ongoing evolution of services computing, application specific requirements, especially the ones regarding security, changed dramatically. Whereas before outsourcing, when an application basically only needed to be secured against outsider attacks, in this new services computing paradigm, this requirement has drastically changed, as a malicious user now has the possibility to invade a system by already starting from its internals, due to the shared runtime environment [4]. Current security testing approaches fail to address such requirements, e.g., testing against insider attacks (see Section III). Besides their shared environment, that poses new require- ments for security testing, another serious issue for security testing arises when considering the domains of an ScS and their requirements. Here we distinguish between two domains, viz. the business domain, referring to the type of the system (e.g., e–Health or Enterprise Resource Planning), and the technological domain, referring to technological aspects of the ScS (e.g., what technology is used for service provisioning). Also important for testing is the specific intended functionality of the service. Is the service a building block for a composed service and hence, needs some kind of integration testing or is it just a simple management service, whose proper functioning can be assured by unit testing? Keeping these in mind requires to do much testing following different approaches to meet all requirements. And yet, this kind of testing does not even regard security related aspects at all. Adding the additional effort, necessary to do security testing in a meaningful manner, results in a long–lasting software development process that consumes high expenses. This testing dilemma becomes even worse if taking the insufficient tool support for security testing into account (see Section III). What also makes security testing in such a service–centric environment challenging is, that testing needs to be feasible for both the service providers and the service consumers. The former wants to test services before deploying and providing them, whereas the latter in addition must have the possibility to test services before consuming or integrating them in their own applications and business processes. What has to be kept in mind at this point is a potential lack in technical knowledge by at least the service consumer. Current security testing approaches fail to abstract the necessary level of technical knowledge for that untrained developers can successfully test software systems on their own [5]. In our paper we identify drawbacks of current security test- ing approaches for ScS and, based on those drawbacks identify emerging requirements for future security testing approaches. We also introduce and motivate the idea of language–oriented security testing, a novel approach that attempts to focus especially on these requirements by applying domain specific abstractions. Additionally, we provide an in-depth discussion of our novel approach. Hence, the main contributions of our paper are: 2013 Seventh International Conference on Software Security and Reliability Companion 978-0-7695-5030-5/13 $26.00 © 2013 IEEE DOI 10.1109/SERE-C.2013.16 53