Attack scripts generation for security validation fr


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Attack scripts generation for security validation fr

  1. 1. Attack scripts generation for security validation Anderson Morais* — Ana Cavalli** — Eliane Martins* *Institut Télécom / Télécom SudParis 9, rue Charles Fourier, 91011 Évry Cedex, France {anderson.morais,ana.cavalli} ** Institute of Computing - State University of Campinas Av. Albert Einstein 1251, 13083-970 Campinas SP, Brazil ABSTRACT: In this paper we present an original approach to generate attack scripts aiming at security validation of information systems and applications. The goal is to uncover potential vulnerabilities that an attacker could exploit to cause security failures of the system. We use attack modelling to specify the system flaws and derive the corresponding attack scenarios. The attack scenarios are refined to generic attack scripts using: attack pattern, event- condition-action rule, keyword-driven testing, and UML diagrams. The generic attack scripts are then converted to executable scripts for a testing tool. The generated attack scripts are in a format that is independent of the used tool, i.e., they are reusable. The executable attack scripts are able to simulated real attacks. Examples are provided to show the usage of the approach. RÉSUMÉ: Dans cet article nous présentons une approche originale pour produire des scripts d'attaque visant la validation de la sécurité des systèmes d'information et d'applications. L'objectif est de découvrir les potentielles vulnérabilités qu'un attaquant pourrait exploiter pour causer des défaillances de sécurité du système. Nous utilisons modélisation d’attaque pour spécifier les failles du système et dériver les correspondants scénarios d'attaques. Les scénarios d'attaque sont raffinés à des scripts d'attaque génériques avec l'aide de : l’attack pattern, la règle event-condition-action, le keyword-driven testing, et des diagrammes UML. Les scripts d'attaque génériques sont ensuite convertis en scripts exécutables pour un outil de test. Les scripts d'attaque sont générés dans un format qui est indépendante de l'outil utilisé, c'est à dire, ils sont réutilisables. Les scripts d'attaque exécutables peuvent simuler des attaques réelles. Des exemples sont donnés pour montrer l'utilisation de l'approche. KEY WORDS: security validation, attack scripts, security testing. MOTS-CLÉS: validation de sécurité, scripts d'attaque, test de sécurité. SEC-SY 2010
  2. 2. 2 SEC-SY 2010 1. Introduction Security and reliability have become a major concern for information systems as well as for service oriented applications. The security of these systems becomes even more important since we rely on them for our everyday life activities and tasks. What we cannot ignore, however, are the systems security vulnerabilities, resulting not only from bugs introduced during the software development phases but also from the environment where these systems are deployed for operation, which could be exploited by malicious adversaries. Software security is in a critical state. Statistics published by NIST National Vulnerability Database (NIST, 2010) reported 5733 known software vulnerabilities in 2009, which correspond to an increase of 134% from 2004, and an increase of 2% from 2008. The existence of vulnerabilities does not cause a security failure, and in fact many times they can remain dormant for a long time. An intrusion is only materialized when an attack has been successful in exploiting a vulnerability. After an intrusion, the system might or might not fail, depending on the kind of mechanisms the system possesses to handle errors introduced by the adversary. Sometimes an intrusion can be tolerated as the error is detected and isolated, but in the majority of the current systems, it leads immediately to violation of one or more security properties (e.g., confidentiality or availability), i.e., a security failure occurs. Vulnerability removal is thus very important method to reduce the risk of successful attacks, by reducing the number or severity of vulnerabilities. Different Verification and Validation (V&V) techniques can be used for that purpose during the system development, such as static verification techniques: analysis (Edge et al., 2007), formal proofs (Gray et al., 1995), model checking (Lowe 1998); or dynamic verification techniques: testing (Orset et al., 2007). The identified flaws may then be removed by fixing the software code. In this work we focus on dynamic verification, or usually termed active testing, where the system code is exercised by providing real inputs while its security mechanisms are evaluated. Some works have used active testing to evaluate the system security, where attack scenarios are generated, but a systematic methodology is not employed. For example, (Thompson et al., 2002) tested software security in a hostile environment. Faults were injected during runtime by monitoring and modifying system calls made by the application to the operating system. In this sense, they emulate the behaviour of a hostile environment. However, they do not mention how to associate this behaviour with attacks. The work (Wanner et al., 2003) presents the design and development of a fault injector tool for testing of firewalls and intrusion detection systems. The fault injector provides functions to the user, such as dnsspoof, tcpkill and others, to simulate attacks to TCP/IP protocols. The PROTOS (Protos 2001) and SPIKE (Aitel 2002) tools generate attacks using Fuzzing – the inputs are randomly generated – and syntax testing techniques, where the inputs of the application are corrupted with known malicious attack patterns,
  3. 3. Attack scripts generation for security validation 3 such as long string or invalid characters. The mutation of inputs is based on the specification of the input format. But security vulnerabilities are exploited in a limited way since there is no relation between the provided inputs and the found vulnerabilities, i.e., inputs that an attacker do use in real-life are hardly replicated using this technique. In these works it is not mentioned how to model the malicious inputs that are used during testing, not allowing them to be reused in similar applications neither ported to different tools. A great number of testing experiments is needed to detect a vulnerability alone, which impacts on the efficiency of these approaches. In this paper we describe an original approach to generate attack scripts in order to validate the security aspects of the target system. The vulnerabilities can be detected in the presence of attacks that are emulated running these scripts. Despite of using mutation technique on the inputs to produce attacks we propose the use of attack modelling technique to help to uncover security vulnerabilities. The threat model represents real attacks and known vulnerabilities of the system. The model is easy to maintain, to keep updated, and can be reused in similar applications. Attack modelling has been used for: representing the steps of threats to a system and classifying them (Edge et al., 2007) for helping identifying known vulnerabilities and weak parts of the system that could be exploited by a attacker; modelling software components under security perspective by adding security information to UML diagrams (UMLsec – UML for secure systems); specifying intrusion scenarios (Hussein et al., 2006) and generating signatures using UML diagrams (UMLintr – UML for intrusion specifications). The attack scenarios are automatically generated from the threat model. After describing these attack scenarios using the attack pattern technique (Moore et al., 2001), we can represent them with event-condition-action (ECA) rule (Paton et al., 1993), keyword vocabulary, and intrusion specification UML elements. So we obtain generic attack scripts from the attack scenarios, which can be converted to executable attack scripts for testing tools. In this way the approach does not depends on the system source code neither on a unique testing tool. The goal of the approach is to increase the testing controllability and decrease the high number of inputs as it is done in traditional security testing, i.e., improve the overall testing efficiency. The main contributions this paper brings are: − An original approach to generate attack scripts based on modelling of real attacks; − A complete methodology to convert from attack scenarios to executable scripts; − Easy methods to produce generic attacks scripts that are reusable in different architectures and testing tools. The paper is structured as follows. Section 2 contains a description of the
  4. 4. 4 SEC-SY 2010 approach showing how to obtain attack scenarios from the threat model. Section 3 explains how to transform from attack scenarios to generic attack scripts and after to executable attack scripts. Section 4 closes the paper by presenting the results and some directions for future works. 2. Attack modelling approach The purpose of the approach is to demonstrate how testing engineers or developers can generate attacks scripts to evaluate the security level of systems and find potential security flaws in the implementation in a feasible time interval with good efficiency. Figure 1 illustrates the steps of the approach. Steps from 1 and 2 are presented in the remainder of this section. 1. Attack modelling: 2. Generate attack - Identify the threats Threat model scenarios - Define attacker capabilities 3. Refine attack scenarios: Attack scenarios Generic attack attack pattern + ECA rule + scripts keyword vocabulary + UML. 4. Transform attack Executable scripts: converter attack scripts Figure 1. Approach to generate attack scripts. Firstly we take information of vulnerabilities and attacks to the system to define the threats to be modelled. This information is usually available in vulnerabilities databases (ex.: NIST - National Vulnerability Database. It contains: general information of the vulnerability such as: release date, description, etc; metrics of the vulnerability such as: complexity, exploitability, violated security properties, etc. For this work we use: description and violated security properties information. Then what we have to do is: collect as many as possible vulnerabilities related to the target system from these databases and sort them according to the violated security property (ex.: integrity, confidentiality). We also have to define the attacker capabilities, i.e., what means the attacker owns to carry out the attacks (ex.: he has access to the Web server). In this way, we can make sure the selected attack scenarios can be executed by the testing tool that represents the attacker. We have to use the collected vulnerabilities information – description and violated security properties – and the attacker capabilities parameters to build the threat model of the target system. Threat models range from attack tree models
  5. 5. Attack scripts generation for security validation 5 (Morais et al., 2009) to more formal petri net based methods. Methods based on UML notations (Hussein et al., 2006), such as use-cases, classes, state-machines have also been adopted over the last years. The attack tree usage is demonstrated in work (Morais et al., 2009). But the tester is free to choose the attack model representation that best satisfies his needs. The attack scenarios are generated from the threat model. A selection criterion must be defined to perform the searching on the threat model in order to find the appropriated attack scenarios to be refined. A criterion can be: “to cover all attack scenarios matching the attacker capabilities parameters”, i.e., the attack scenarios that can be emulated by the testing tool. This step is completely automated since most of tools that support the construction of threat models can also select scenarios based on a criterion. The obtained scenarios can be used to create an attack library, which is useful for testing other systems from the same family. 3. Attack scripts generation The first sub-step of the refinement step is to describe the attack scenario using the attack pattern technique (Moore et al., 2001). We make use of the following attack pattern elements to separate the attack scenario into steps: (1) “the overall goal of the attack” == “the attack scenario”; (2) “a list of preconditions for its use” == “system or/and environments events”, which are extracted from the attack description; (3) “the steps for carrying out the attack” == “tasks the attacker must accomplish”, which are also extracted from the attack description. We selected the “SSLv.3/TLSv.1 truncation attack” to illustrate the refinement step. The attack is executed when tearing down an SSL/TLS connection between a Web browser and a Web server. The attack description is: “the attacker drops the last application data record (PDU) and the closure Alert Message close_notify transmitted from the server to the client when closing a TCP connection, making it appear that the whole message sent to client is shorter”. The violated security property is: integrity. Figure 2 shows the attack pattern representation for this attack. (1) Goal: SSLv.3/TLSv.1 truncation attack (2) Precondition: PDU from the server to the client (3) Steps: AND 1. if record (PDU) is application data 2. if record (PDU) is the last one 3. drop last record (PDU) 4. if record (PDU) is Alert Message 5. if record (PDU) of Alert Message is close_notify 6. drop record (PDU) close_notify Figure 2. Attack pattern for attack scenario.
  6. 6. 6 SEC-SY 2010 For the second sub-step of the refinement we use the event-condition-action (ECA) rule (Paton et al., 1993) to represent the attack pattern elements showed in Figure 2. An ECA rule performs actions in response to events, given that a stated condition holds. An ECA rule has the general syntax: <ON event IF condition DO action>. The event part specifies when the rule is triggered: event == (2) Precondition. The condition part determines if the data are in a particular state, in which case the rule fires: condition == (3) Steps, when there is ‘if’. The action part describes the actions to be performed if the rule fires: action == (3) Steps, when there is attacker action. We use a keyword vocabulary to describe the ECA rule parts. This method is applied in keyword-driven testing1 or table-driven testing, where keywords are selected by an experienced tester according to software domain during the planning phase. The tests are developed as data tables using a keyword vocabulary that is independent of the testing tool used to execute them. Such data table records contain the keywords that describe the actions we want to perform. In Figure 3 the data table contain keywords that describe the parts of ECA rule. The software domain taken into account is a communication system, where participants exchange messages. The keywords for ECA rule’s part action mean what an attacker can perform on the communication network, i.e., his capabilities. ECA rule part Keywords send(A,B,m,<TP>,<IP_A>,<IP_B>,<Po_A>,<Po_B>), event rcv(B,A,m,<TP>,<IP_B>,<IP_A>,<Po_B>,<Po_A>) condition m.PDU_type, m.<field>, var, protocol.<prop> intercept(m), corrupt(m.<field>),drop(m), duplicate(m), delay(m), impersonate.create(m), action impersonate.send(m), store(m.<field>), restore(m.<field>), sign.set(var), sign.get(var) Legend: -send: send a message, – rcv: receive a message. – A: sender, – B: receiver. – m: message, – <TP>: transport protocol (ex.: TCP, UDP). – <IP_A>: source IP, – <IP_B>: destination IP. – <Po_A>: source port, – <Po_B>: destination port. – m.PDU_type: message PDU type (ex.: data PDU), – m.<field>: message field. – var: state variable, – protocol.<prop>: protocol specification properties. Figure 3. Data table for ECA rule. The attack pattern elements of truncation attack in Figure 2 are then converted to the ECA rule parts, as shown in Figure 4: event = (2) Precondition; condition = (3) Steps 1, 2, 4, 5; action = (3) Steps 3, 6. We can group syntactically the elements 1, 2 and the elements 4, 5 using operator AND. Two ECA rules are created. The ECA 1
  7. 7. Attack scripts generation for security validation 7 rules parts are then specified using the keywords of Figure 3’s table as shown in Figure 4. Rule 1: ON event: send(A,B,m,<TP=TCP>,<IP_A>,<IP_B>,<Po_A>,<Po_B>) IF condition: (1. m.PDU_type == protocol.<prop=application_data>) AND (2. m.<field=record_sequence> == LAST) DO action: 3. drop(m) Rule 2: ON event: send(A,B,m,<TP=TCP>,<IP_A>,<IP_B>,<Po_A>,<Po_B>) IF condition: (4. m.PDU_type == protocol.<prop=alert>) AND (5. m.<field =alert_description> == protocol.<prop=close_notify>) DO action: 6. drop(m) Figure 4. ECA rules for attack pattern. The third sub-step is to identify the UML elements that implement the ECA rule and the respective keywords to generate the generic attack script. We propose the use of interface components (Bachmann et al., 2000), which allows a more black- box approach and allows reusability and flexibility. We define three interfaces: Attacker, Attack and Victim, which represent three components that provide services through their operations. The Attacker interface represents the attacker capabilities and provides operations to represent ECA rule’s keywords. The Victim interface represents the target system along with its specification properties. The Attack interface represents the generated attack scenario and will coordinate the attack steps using operations of Attacker and Victim interfaces. Table 1 shows the interfaces and their operations. Attacker and Victim interfaces’ operations are directly mapped to the ECA rule’s parts and keywords, as shown in Table 1, where: event maps from the Attacker’s operations for message analysis; condition maps from the Attacker’s operations for message data extraction, which are compared to the properties of target application extracted from Victim’s operation; action maps from the Attacker’s operations related to the attacker capabilities. The final sub-step consists of implementing the generic attack script: first we take mainAttack operation of Attack interface that will perform the attack steps; second we take getProperties operation of Victim interface to extract the system properties values – the script’s constants; and third we implement the script’s logic taking the Attacker’s operations in Table 1 that are mapped to the keywords of each ECA rule part, following the syntax: <ON event IF condition DO action>. Figure 5 shows generic attack script template.
  8. 8. 8 SEC-SY 2010 Interface Part Keywords Interface Operations getProtocolType: send(<TP>…),rcv(<TP>…) Protocol_Type send(<IP_A>…),rcv(<IP_A>…) getSourceIP: IP_Address event getDestinationIP: send(<IP_B>…),rcv(<IP_B>…) IP_Address send(<Po_A>…),rcv(<Po_A>…) getSourcePort: Port send(<Po_B>…),rcv(<Po_B>…) getDestinationPort: Port m.PDU_type getPDUType: PDU_Type condition m.<field> getPDUField: PDU_Field intercept(m) InterceptPacket: Packet Attacker drop(m) DropPacket: Action delay(m) DelayPacket: Action duplicate(m) DuplicatePacket: Action impersonate.create(m) CreatePacket: Packet action impersonate.send(m) SendPacket: Packet corrupt(m.<field>) CorruptPDUField: Action store(m.<field>) StorePDUField: PDUField restore(m.<field>) RestorePDUField:PDUField sign.set(var) SetFlag: Boolean sign.get(var) GetFlag: Boolean getProperties: Victim condition protocol.<prop> Protocol_properties Attack mainAttack Table 1. Interfaces and operations mapped to ECA rule and keywords. 1. class Attack_Script implements Attack { 2. mainAttack() { 3. Packet packet; 4. properties = <>.getProperties(protocol); 5. while (packet = <>.InterceptPacket()){ 6. /*event operations */ 7.Rule_1: 8. /*condition and action operations*/ 9.Rule_2: 10. /*condition and action operations*/ 11. … 12.Rule_n: 13. /*condition and action operations*/ 14. return; /* End of attack */ 15.}}} Figure 5. Generic attack script template.
  9. 9. Attack scripts generation for security validation 9 1. class Attack_Script implements Attack { 2. mainAttack() { 3. Protocol_Type TCP; Port Webserver_port; 4. PDU_Type application_data; PDU_Type alert; 5. PDU_Field record_sequence; PDU_Field alert_description; 6. PDU_Field lastRecord = LAST; PDU_Field close = close_notify; 7. Boolean truncate; Packet packet; converter Converter; 8. UDP, Webserver_port, application_data, alert, record_sequence, 9. alert_description = converter.getProperties(TLS); 10. while (packet==converter.InterceptPacket()){ 11. if (converter.getProtocolType(packet) == TCP) 12. and (converter.getSourcePort(packet) == Webserver_port){ 13.Rule_1: 14. if (converter.getPDUType(packet) == application_data)and 15. (converter.getPDUField(packet,record_sequence) == lastRecord){ 16. converter.DropPacket(packet); 17.Rule_2: 18. if (converter.getPDUType(packet) == alert)and 19. (converter.getPDUField(packet,alert_description) == close){ 20. converter.DropPacket(packet); 21. return; /* End of attack */ 22.}}}} Figure 6. Generic attack script implementation. Finally the generic attack script is implemented according to the template in Figure 5 and Figure 4’s ECA rules. The generic attack script implements mainAttack operation of Attacker interface as shown in Figure 6. This script can be reused for testing other similar implementations, what hardly occurs with traditional security testing approaches. 3.1. Attack scripts transformation The generic attack script’s operations are transformed into the specific language of the testing component, prior to execution, using a converter. The converter is modelled based on the adapter design pattern (Gamma et al., 1995). Figure 7 illustrates the class diagram containing the converter. The Attack_Script()class implements Attacker interface and desire to use Testing_Tool() class operations. The Converter() class – that represents the converter – implements the operations of Attacker and Victim interfaces which are used by the generic attack script Attack_Script()class as shown in Figure 6. So operations of Converter()class call and translate the operations of Testing_Tool()class – that uses specific tool language – to be understood and used by Attack_Script() class. Then Attack_Script() class can call operations of Converter() class that call Testing_Tool() class operations, which return the desired tool language instructions. This capacity to port a generic attack script to different testing tools is not found in traditional security testing approaches.
  10. 10. 10 SEC-SY 2010 package Data[ Conversor ] Attack Victim Attacker +mainAttack() +getProperties() : Protocol_properties +InterceptPacket() : Packet Converter The class operations Attack_Script +tool : Testing_Tool are not exhibited. +converter : Converter +getProperties() : Protocol_properties +InterceptPacket() : Packet +mainAttack() The other operations of Attacker interface Testing_tool are not exhibited. ... converter.InterceptPacket(); +InterceptPacket() : Packet ... ... tool.InterceptPacket(); The other operations ... of Testing_Tool class are not exhibited. Figure 7. Class diagram for attacking components. Operation Instructions converter.getProperties These values are obtained from system’s specification converter.InterceptPacket(interface) This operation is executed by the tool SET 0x9 R0 #TCP field offset READB R0 R1 converter.getProtocolType(packet) SUB R1 R6 == TCP JMPZ R6 IS_TCP JMP ERROR_OK SET 0x14 R0 #port field offset READS R0 R1 converter.getSourcePort(packet) SUB R1 R7 == Webserver_port JMPZ R7 TO_BROWSER JMP ERROR_OK SET 0x1C R0 #PDU field offset READB R0 R1 SET 0x0F R0 #PDU byte mask converter.getPDUType(packet) == application_data AND R0 R1 SUB R8 R1 JMPZ R1 PDU_AD JMP ERROR_OK READS R9 R1 converter.getPDUField(packet, SUB R5 R1 record_sequence) == lastRecord JMPZ R1 DO_TRUNC JMP ERROR_OK DRP converter.DropPacket(packet) JMP INIT
  11. 11. Attack scripts generation for security validation 11 Table 2. Mapping from operations to tool’s instructions. We use the Firmament testing tool (Drebes et al., 2005) to exemplify this step. The Table 2 shows the indirect mapping from operations of Attack_Script()class to Firmament’s language instructions. Using this mapping for the converter and mainAttack operation’s logic in Figure 6 we can easily obtain the final executable attack script. 4. Conclusions and Future Work In this paper we proposed an original approach to generate executable attack scripts for security testing in an efficient way. Attacks scenarios are generated from a threat model. The threat model is build from real vulnerabilities and known attacks that are taken from global vulnerabilities databases. The approach shows how to select attack scenarios that are feasible for a testing tool. One of the main contributions of this work is the notation based on UML to represent attack scenarios and generate platform independent attack scripts. The approach also describes a converter to transform generic scripts to executable scripts, making it possible to port the script to an ample gamma of testing tools. One possible future work is to use an existing attack language to represent the attack scenarios in order to enhance the approach flexibility and portability. We can use other vulnerabilities attributes from the databases for the attack modelling to improve the scenarios searching and sorting. It is also necessary to create a systematized method to generate unknown attacks from reported attacks so that new vulnerabilities can be uncovered during the testing. 5. References A. Morais, E. Martins, A. Cavalli, W. Jimenez, "Security Protocol Testing Using Attack Trees," cse, vol. 2, pp.690-697, 2009 International Conference on Computational Science and Engineering, Vancouver, 2009 A.P.Moore, R.J.Ellison, R.C.Linger. Attack Modelling for Information Security and Survivability. Technical Note CMU/SEI-2001-TN-001. March 2001. D. Aitel, “The Advantages of Block-Based Protocol Analysis for Security Testing”, Immunity Inc., February 2002. Obtained in May/2009 at: downloads/advantages_of_block_based_analysis.html. E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1995. F. Bachmann et al. Volume II:. Technical Concepts of Component-Based Software Engineering - 2nd Edition. Obtained in Abr/2010 at:
  12. 12. 12 SEC-SY 2010 Herbert H. Thompson, James A. Whittaker, Florence E. Mottay, “Software security vulnerability testing in hostile environments”, ACM Symposium on Applied Computing (SAC) 2002: 260-264. Madrid, Spain. James W. Gray III, John McLean, “Using temporal logic to specify and verify cryptographic protocols”, Proc. of 8th. IEEE Computer Security Foundations Workshop (CSFW '95), March 13-15, 1995, Kenmare, County Kerry, Ireland, pp 108-117. J.M. Orset, B. Alcalde and A. Cavalli, “A formal approach for detecting attacks in ad hoc networks”, International Journal of Network Security, 2(2): 141-149, 2007. G. Lowe, “Towards a Completeness Result for Model Checking of Security Protocols”, Proceedings of the 11th Computer Security Foundations Workshop (PCSFW), IEEE Computer Society Press, 1998. Hussein, M., Zulkernine, M., “UMLintr: a UML profile for specifying intrusions”. In Proceedings of the IEEE International Conference and Workshop on the Engineering of Computer-Based Systems, Tucson, AZ, USA, pp. 279–288 (2006). K. S. Edge, R. A. Raines, R. O. Baldwin, M. A. Grimaila, and R. Bennington, “The Use of Attack and Protection Trees to Analyze Security for an Online Banking System”, the Hawaii International Conference on System Sciences-HICSS-40, Kauai, Hawaii, January 2007, 8 pages (CD) NIST National Vulnerability Database, 2010, statistics 2004-2010, N. Paton, O. Díaz, M.H. Williams, J. Campin, A. Dinn e A. Jaime. “Dimensions of Active Behaviour”. In N. Paton et M. Williams, editor, Proceedings of 1st Int. Workshop on Rules in Database Systems (RIDS’93), Edinburgh - Scotland, September 1993. Springer Verlag. P.C.H.Wanner, R.F.Weber. “Fault Injection Tool for Network Security Evaluation”. LNCS Volume 2847/2003, Dependable Computing, Pp 127-136, Sept/2003. PROTOS - Security Testing of Protocol Implementations, obtained in May/2009 at: http:// R.J. Drebes, G. Jacques-Silva, J. F. da Trindade, T. S. Weber, “A Kernel-based Communication Fault Injector for Dependability Testing of Distributed Systems”. Parallel and Distributed Systems: Testing and Debugging (PADTAD-3), 2005, Haifa, Israel.