SecureSphere Web Application Firewall Test Drive

Protecting applications against SQL Injection and Zero-Day Attacks SecureSphere Web Application Firewall Test Drive The purpose of this Test Drive is to enable customers to rapidly evaluate SecureSphere Web Application Firewall (WAF) features. This Test Drive is focused on demonstrating how SecureSphere protects against advanced cyber threats such as SQL Injection and Zero-Day Attack

Contents Preface... 2 Requirements... 2 Common Terms... 2 Introduction to SecureSphere WAF... 3 Key Capabilities... 3 Lab Objectives... 6 SecureSphere Test Drive Sign-up and Launch... 7 Sign-Up for the Test Drive... 7 Launch SecureSphere Test Drive... 8 Test Drive Environment... 16 Lab 1: Protect Against SQL Injection... 19 Overview... 19 Test Drive Lab Procedure... 20 Lab 1 Conclusion... 27 Create your Zero-Day attack... 28 Lab 2 Conclusion... 33 SecureSphere WAF Test Drive FAQ... 34 Copyright Notice... 35 Contacting Imperva... 36 Headquarters... 36 SecureSphere WAF Test Drive 1

Preface This Test Drive allows you to quickly and easily explore the benefits of using Imperva SecureSphere WAF to protect your applications. This lab was developed by Imperva and is provided free of charge for educational and demonstration purposes. Requirements Internet Access Remote Desktop Protocol (RDP) client on your local machine Access to an email account to receive login credentials RDP port is open to Amazon.com to connect to the Attacker s Workstation For a better browser experience, you can (optionally) access the SecureSphere manager over TCP port 8083 (if open on your network) Common Terms The terms below are used throughout the document. Term Attacker s Workstation Web Application Firewall (WAF) SecureSphere SecureSphere Manager (MX) SecureSphere Gateway SQL Injection Definition A Windows machine that was set up for the purpose of sending attacks, as well as optionally accessing the SecureSphere GUI. A WAF stops attacks on HTTP servers, preventing a myriad of attacks that NextGen Firewalls and IPD/IDS products cannot protect against. Imperva s comprehensive, integrated security platform that includes SecureSphere Web, Database and File Security. A web based GUI that unifies the administration, logging, and reporting of multiple SecureSphere gateways. Inspects and passes traffic to the destination webservers. A code injection technique, used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SecureSphere WAF Test Drive 2

Introduction to SecureSphere WAF Your website receives a continuous barrage of attacks. If hackers uncover a crack in your defenses, they can steal your application data, defraud your users, and take down your website. The SecureSphere WAF stops web attacks and prevents costly data breaches and downtime. Combining multiple defenses, SecureSphere accurately pinpoints and blocks attacks without blocking your customers. It offers drop-in deployment and automated management. Certified by ICSA Labs, SecureSphere satisfies PCI 6.6 compliance and provides ironclad protection against the OWASP Top Ten. Key Capabilities Block Attacks with Laser Precision Security accuracy is job number one at Imperva. We know you re just as concerned about blocking legitimate users as you are about stopping attacks. With that in mind, we ve developed Dynamic Profiling technology to automatically build a white list of acceptable user behavior. And we use Correlated Attack Validation to correlate Dynamic Profiling violations with other suspicious activity to correctly identify attacks without blocking your customers. Leverage World-Renowned Application Security Research To get ahead and stay ahead in the continuous fight against application attacks, you need your own security research organization. SecureSphere WAF customers get exactly that with regular signature and policy updates from our dedicated security research team, the Application Defense Center (ADC). ADC research yields the most up-to-date threat intelligence, and the most complete set of application signatures and policies in the industry. SecureSphere WAF Test Drive 3

Shut Down Malicious Sources and Bots Can you distinguish between real customers, known attackers, or bots? Can you tell if website visitors are using anonymous proxies to cloak their identity? ThreatRadar Reputation Services detects these users with IP reputation feeds of malicious sources, anonymizing services, phishing URLs, and IP geolocation data. ThreatRadar delivers an up-to-date and automated defense against automated attacks and attack sources to help you maximize uptime and protect your sensitive data. Stop Application DDoS and Business Logic Attacks You can keep your customers happy and your reputation intact in spite of the growing threat of business logic attacks. Business logic attacks exploit the normal logic of your applications to post comment spam in forums and message boards, scrape web content, or disable access to your website. All of this can reduce your competitive edge, frustrate customers, and damage your reputation. SecureSphere mitigates these concerns by identifying bots, known attack sources, and attack behavior. Instantly Patch Website Vulnerabilities Application vulnerabilities can leave your company exposed to attack for weeks or months. SecureSphere integrates with application scanners for virtual patching, importing assessment results, and creating custom policies to remediate vulnerabilities. Compared to manually fixing website vulnerabilities, virtual patching reduces the window of exposure and costs. SecureSphere WAF Test Drive 4

Gain Forensics Insights with Customizable Reports You can quickly analyze security threats and meet compliance requirements with graphical reports. SecureSphere provides both pre-defined and fully-customizable reports. Reports can be viewed on demand or emailed on a daily, weekly, or monthly basis. A real-time dashboard provides you with a high level view of system status and security events. Speed up Deployment without Risk Now you can protect your applications without impacting performance and without requiring extensive network changes. SecureSphere offers flexible inline, non-inline, and proxy deployment options that meet your organizations diverse requirements. SecureSphere s unique, transparent bridge mode saves time and labor with drop-in deployment that requires no changes to existing applications or network devices. SecureSphere also delivers multi-gigabit throughput while maintaining submillisecond latency. Data Center Security Leader We fill the gaps in traditional security by directly protecting high-value applications and data assets in physical and virtual data centers. SecureSphere WAF Test Drive 5

Lab Objectives The objectives of these labs are to demonstrate the capability of SecureSphere to protect against SQL Injection and Zero-Day Attacks. Participants will understand: What type of damage a successful SQL Injection attack can cause The challenges of protecting against a Zero-Day attack How SecureSphere views the attacks How SecureSphere can protect against the attacks Additionally, Test Drivers are welcome to browse the GUI, generate different types of attacks against the target server, or evaluate a feature. SecureSphere WAF Test Drive 6

SecureSphere Test Drive Sign-up and Launch Sign-Up for the Test Drive 1. Go to Amazon s Security Test Drive page: http://aws.amazon.com/testdrive/security/ 2. Click on the SecureSphere Try it now free button. 3. Complete the registration form 4. Click on Signup 5. Click on Continue 6. Click on Test Drives SecureSphere WAF Test Drive 7

7. Click on the Enter button 8. You have the opportunity to watch our video, download the PDF Guide, and launch the Test Drive cloud. We recommend starting with the video, reviewing the Test Drive Lab Manual, and then launching the Test Drive. Launch SecureSphere Test Drive 9. Click on the Launch Test Drive button 10. Wait for the launch to complete. Once it s completed, the progress bar will show In Progress SecureSphere WAF Test Drive 8

Once you see In Progress turn Green, you can proceed to the next step. 11. Check your email for the link to the Management Server (MX). Alternatively, you can copy & paste the link from the bottom right-hand quadrant of the Test Drive GUI, in the Environment window. For example: Your Email will look similar to the one below: SecureSphere WAF Test Drive 9

Hello Edgard, Your SecureSphere Test Drive has been created and is ready for you to use. Please remember that after 3 hours the environment will no longer be available. The information you need to login and use your TestDrive is available below. From your location, you will need access to the Amazon Cloud. At a minimum, RDP protocol and (optionally) TCP Port 8083 must be allowed outbound to AWS. You can use Remote Desktop client to RDP to the IP address of Windows Attacker Machine, and login using these credentials below You can access the SecureSphere Manager (MX) using a web browser on port 8083(like HTTPS://ip_address:8083 ) If you dont have access to port 8083, the Windows Attacker Machine is able to login to the MX Login for Windows Machine: User: TestDrive Password: Imperva1 Login for SecureSphere Manager: User: admin Password: aws_is_cool1 Your IP address is below: The Imperva Management Server IP and Username: admin and password aws_is_cool1.: https://ec2-54-183-14-120.us-west-1.compute.amazonaws.com:8083 You can RDP to the IP address of Windows Attacker Machine using Username: TestDrive and Password Imperva1. The IP Address is : 54.183.118.43 Use the Windows Attacker machine to attack this URL of the Web-Server : http://orbiterat-elbexter-15hha3rdxnmci-1823771081.us-west- 1.elb.amazonaws.com *Note: Please wait for ~5-8 minutes before accessing the URLs as some resources may take a few extra minutes to become available, depending on AWS resource availability. The login instructions are presented at the bottom of the email. There, you will find your link to login to the MX, and the IP address of the Attacker s Workstation. Your URL to the MX will look similar to this: https://ec2-54-183-14-120.us-west-1.compute.amazonaws.com:8083 SecureSphere on AWS Test Drive 10

TIP: If you are unable to access the link provided in the email, proceed to Step 16 (accessing the Attacker s Workstation using RDP), then return to this step after you ve accessed the desktop of the Attacker s Workstation. The Attacker s Workstation can access the MX GUI, so accessing it directly is optional, but preferred. Alternatively, once the Test Drive has finished launching you can obtain the necessary login information from the Environment window. SecureSphere on AWS Test Drive 11

12. Accept the untrusted HTTPS connection using your browsers standard process. (We do not generate trusted certificates for Test Drive since they are only live for a few hours): 13. Log into the GUI using the username and password provided in the email or in the Environment window of the Test Drive signup portal. SecureSphere on AWS Test Drive 12

14. You may have to wait a few minutes for the server to complete its initial load: 15. You are now in the SecureSphere GUI. If you are unable to connect, you might have a blocked port. If you suspect your port is blocked, you can test it here: http://portquiz.net:8083/ If you are unable to access a webpage at that address, ask your system administrator to open outbound TCP port 8083. You will also want to check your local firewall to make sure it s not blocked on your workstation. You can proceed to the next step, and access the Management Server (MX) from the Attacker s Workstation. 16. From your local workstation, access the Attacker s Workstation using Remote Desktop Protocol (RDP). In Windows, you can accomplish this by going to the command prompt, typing mstsc, and pressing enter. SecureSphere on AWS Test Drive 13

17. Enter the IP address of the Attacker s Workstation that was provided in your email, or from the OUTPUT window of the Test Drive signup portal. 18. Once prompted, enter your credentials to access the Attacker s Workstation. SecureSphere on AWS Test Drive 14

19. Click YES to accept the RDP session certificate. 20. You are now connected to the Attacker s Workstation. From this workstation, you can access the SecureSphere Management Server (MX) and generate attacks to the demo webserver (SuperVeda). SecureSphere on AWS Test Drive 15

Test Drive Environment 4 RDP Web GUI (Alternate) Attacker 1 HTTP Web GUI Manage SecureSphere Admin 2 3 SecureSphere Gateways HTTP SuperVeda Webserver 1 SecureSphere Admin This is your role, the person that uses a web browser to connect to the MX, using HTTPS on port 8083. You will also use Remote Desktop from your machine to the Windows machine we ve created for you in AWS to attack SuperVeda. The same machine can act as both SecureSphere Admin and Attacker, in case your browser cannot access port 8083 to the MX. 2 SecureSphere MX The MX controls the security policies, profiles, configurations, alerts, and other functionality. The MX pushes the appropriate configuration to the Gateways after each change. 3 SecureSphere Gateways The Gateways provide proxy functionality for the traffic. Only traffic that s load balanced (in this case HTTP/HTTPS) is passed on to the webserver all other traffic is dropped. After inspecting the HTTP traffic against the policies and inspection engines, the traffic is proxied to the SuperVeda webserver. 4 Attacker s Workstation This is the Windows machine that you are RDP d to, and can also access the MX. 5 SuperVeda The vulnerable target that we will be attacking, then subsequently protecting. SecureSphere on AWS Test Drive 16

Within AWS, we ve created all of the necessary components to provide enough infrastructure to complete this Test Drive. This is not necessarily the way Imperva recommends deployment of SecureSphere, this design is solely for the purpose of this Test Drive. The AWS Architecture is represented below: SuperVeda For the purposes of this Test Drive, we will be using a website that s been created specifically to demonstrate vulnerabilities in web applications. The vulnerable website is for a phony online store we ve developed, called SuperVeda. We will be generating attacks against the SuperVeda website within your own AWS private cloud. No attacks will leave AWS or affect any real company, as long as these instructions are followed and all attacks are targeting the SuperVeda application. In this regard, it s very important to double check your work to ensure you re not accidentally attacking the wrong targets. The testing site SuperVeda is open to many types of attacks, feel free to send a few if you know some off the top of your head. SecureSphere on AWS Test Drive 17

SecureSphere on AWS Test Drive 18

Lab 1: Protect Against SQL Injection Overview In this lab, we will send a SQL Injection attack against the target webserver, view stolen data, and then enable protection against SQL Injection attacks. In order to demonstrate the damage that a SQL Injection attack can do, we will turn off SecureSphere s Block Mode so the attack can pass to the webserver. At a high level, we will follow this process: 1. Ensure the security is disabled 2. Generate SQL Injection attacks 3. View the alerts 4. Turn on Blocking Mode to stop the attacks 5. View the results 6. Summary SecureSphere on AWS Test Drive 19

Test Drive Lab Procedure Disable the security 1. First, make sure you re logged into the Manager GUI and the Attacker s Workstation, as described in the previous section. 2. Make sure that the security is disabled so you can experience the results of a successful attack. In the GUI, we will set the system to Simulation Mode, as shown below: 1. Click on Main 2. Click on Setup 3. Click on Web-Server Group within the left pane 4. Click on Simulation within the right pane 5. Click on Save Generate SQL Injection Attacks 3. Open a web browser and navigate to the SuperVeda Website (the web server) from the Attacker s Workstation. As you can see below, we have an open RDP Session to the Attacker s Workstation SecureSphere on AWS Test Drive 20

with an open web-browser, using the URL that we received in the email. 4. At the end of the URL, paste this SQL Injection code and GO: /showproducts.jsp?catid=1 UNION SELECT 1,Username,1,1,'1','1','1' FROM users So, your URL might look like this (with your IP instead of this sample): http://orbiterat-elbexter-15krx3mqumofb-2144608398.us-west-1.elb.amazonaws.com/showproducts.jsp?catid=1 UNION SELECT 1,Username,1,1,'1','1','1' FROM users The result is a webpage that shows the usernames of the people that have registered, as shown below. SecureSphere on AWS Test Drive 21

5. Since usernames have limited value, we can modify the string to steal passwords, as well as credit card information. To do this, simply change the field you want to steal from the table, as shown below: To steal passwords: http://<server-ip>/showproducts.jsp?catid=1 UNION SELECT 1,Password,1,1,'1','1','1' FROM users To steal Credit Cards: http://<server-ip>/showproducts.jsp?catid=1 UNION SELECT 1,CCNumber,1,1,'1','1','1' FROM users Successfully attacking the server and stealing the credit cards results in a web-page with the credit card numbers listed before the products: SecureSphere on AWS Test Drive 22

View the Alerts 6. In the SecureSphere GUI, take a moment to view the Alerts generated by the attacks you ve generated. 1. Click on Monitor on the top menu 2. Click on Alerts on the sub-menu SecureSphere on AWS Test Drive 23

3. Click on an Alert within the center pane that was generated during your session 4. Click on the + sign within the right pane to view the details of the Alerts 5. Return to step 3 7. Notice that there are several types of Alerts generated during your attack. Protect Against SQL Injection Now, it s time to protect the SuperVeda webserver against attack. To do this, we will reverse what we did in our 1 st step, which was to move to Simulation Mode. Now, we will move to Active Mode where attacks will be blocked instead of solely alerted upon. 8. To move SecureSphere into Blocking Mode, follow the steps below: 1. Click on Setup 2. Click on Web-Server Group within the left pane 3. Click on Active for the Mode selection within the right pane 4. Click on Save SecureSphere on AWS Test Drive 24

9. Open the browser to SuperVeda web server and generate some attacks again, as you did in previous steps. Try to steal usernames, passwords, and credit cards. To steal usernames: /showproducts.jsp?catid=1 UNION SELECT 1,Username,1,1,'1','1','1' FROM users To steal passwords: http://<server-ip>/showproducts.jsp?catid=1 UNION SELECT 1,Password,1,1,'1','1','1' FROM users To steal credit cards: http://<server-ip>/showproducts.jsp?catid=1 UNION SELECT 1,CCNumber,1,1,'1','1','1' FROM users You should receive a Block page which looks like this: SecureSphere on AWS Test Drive 25

10. Check the Alert in the SecureSphere console, as previously described. 1. Click on Monitor on the top menu 2. Click on Alerts on the sub-menu 3. Click on an Alert within the center pane that was generated during your session, it will have the Block symbol )in the 2 nd column. 4. Click on the + sign within the right pane to view the details of the Alerts. 5. Return to step 3 and view additional Alerts SecureSphere on AWS Test Drive 26

Lab 1 Conclusion In this lab, you were able to experience first-hand how a SQL injection attack can easily steal critical information from unprotected web applications. Attackers exploit applications with the goal of stealing sensitive data directly from the datacenter. By constructing a simple text string, we re able to quickly bypass common firewalls and steal usernames, passwords, and credit cards. Next generation firewalls and intrusion prevention systems (IPS) are not equipped to stop application attacks because they do not provide the accuracy, the granularity, or the breadth of protection to thwart Web-based threats. While these solutions protect networks and users, they are ill-equipped to stop attacks that target customers own websites. While next gen firewalls are application aware meaning that they can prevent users from visiting phishing sites or tunneling applications in HTTP they are not designed from the ground up to protect Web applications. As a result, they leave holes in their application defenses defenses that are only addressed by dedicated WAFs. Once Block Mode was initiated in SecureSphere, we were able to stop the attacks across the entire website. Because web application firewalls build a baseline of expected input, they can accurately stop attacks like SQL injection and cross-site scripting. By profiling Web application behavior, for instance, a web application firewall can determine which users should not add brackets, braces, and semi-colons into a zip code field on a registration page, but can enter these same characters into a comment field. Validating input provides the context needed to differentiate between attacks and legitimate requests. SecureSphere on AWS Test Drive 27

Lab 2: Protect against a Zero-Day attack using the Profile Overview In this lab, we will create our own Zero-Day attack, and attempt to send it to the SuperVeda webserver. We will demonstrate how SecureSphere allows legitimate traffic through, while blocking attempts to hack the application. Create a Zero-Day attack Send zero-day attack to SuperVeda View Alert View Profile Create your Zero-Day attack Most attacks follow a structure of some sort. For the purpose of testing in the lab, we don t actually need the Zero-Day to work, we just need to create something that s never been in the wild before. This technique ensures that it will bypass most signature based detection methods. First, we will choose the structure we want to use, which includes the injection, the payload, and the padding. Next, we will inject that attack into a page parameter. For this exercise, use a text editor on your local machine or on the Attacker s Workstation to craft the attack. Normal usage of an HTTP parameter is usually in the format of name=data. Take for example an online store that sells books: it might use an HTTP parameter that looks like: BookName=Security Handbook 2014 Or Author = Dr. Seuss SecureSphere studies and records good transactions, adding them to the application s Profile. By blocking on Profile Violations, the WAF will pass legitimate requests to the SuperVeda webserver, while bad requests are blocked. SecureSphere doesn t have to rely on signatures for attacks, as they are not a reliable protection against zero-day attacks. SecureSphere on AWS Test Drive 28

We will follow this process to create our Zero-Day attack: Choose your attack format Choose your Injection Create the Payload Create the Padding Assemble the attack The Injection is used to break the code and open the door to our Payload. The Payload will contain the destructive code we want to execute. The Padding is used to evade ISD/IPS, or push the code into the correct position to execute properly. Then, we add the Zero-Day attack to a Parameter, so it might look like: BookName=Zero-Day Attack Since Parameters could use a variety of characters, IDS/IPS and Next Gen Firewalls cannot protect against this type of attack. 1. Choose which format you want to use for your Zero-Day attack: 1 2 3 Injection Payload Padding Padding Injection Payload Injection Padding Payload 4 Injection Payload 2. Choose your Injection Choose from one of the following example injections: Choice Injection Potential Purpose 1 ) Breaks webserver code and starts a SQL statement 2 && Makes an AND list 3 > `/. Output Redirection 4 <script> Starts a script 5 Makes an OR list SecureSphere on AWS Test Drive 29

3. Create the Payload To create your payload, choose 2-3 random words and put them together. This will simulate some unforeseen, unknown attack. Some examples are below, but feel free to create your own Payload. Example Payload Potential Purpose 1 quickbrownfox Disables keyboard 2 boomboom Shuts down server 3 Gimme data Steals the database 4 Execute command Runs the command to get a list of processes 5 Ping Imperva.com Tries to ping Imperva.com 4. Create the Padding To create Padding, choose any character, and repeat it several times. Three example Paddings could be: 000 WWWWWWWW %%%%%% 5. Assemble the Attack Assemble the attack by referring to the attack format you chose in step 1. For example, if I chose Format 1, Injection 2, quickbrownfox, and WWWWW as Padding, my Zero- Day attack would like this: Injection && Payload Padding %%%%%% The result would look like this: &&quickbrownfox%%%%%% SecureSphere on AWS Test Drive 30

6. Click on Create an Account within the SuperVeda website. Then, copy & paste the attack into the First Name field. 7. You should receive a Block Page, such as this, which shows that the WAF blocked your Zero-Day attack: SecureSphere on AWS Test Drive 31

8. In the SecureSphere GUI, take a look at the Alerts that were generated from your attack, even though no signature could have detected it. 1. Click on Monitor on the top menu 2. Click on Alerts on the sub-menu 3. View the most recent Alert, located at the top of the center pane. They will have Block symbol ( ) in the 2 nd column. 4. Click on the + sign within the right pane to view the details of the Alerts. 5. Return to step 3 and view additional Alerts SecureSphere on AWS Test Drive 32

Lab 2 Conclusion Despite the best efforts of application developers and IT security teams, most applications have vulnerabilities. In this lab, you were able to create an attack that had never been performed, send it to a web server, and observe the WAF protecting the application from attack. Next-generation firewalls and IDS/IPS solutions lack the capability to enforce good behavior because they rely on signatures of known attacks to protect servers. Zero-day attacks, APTs, and targeted malware easily bypass those solutions, leaving applications open to attack. Through defenses such as patented Dynamic Profiling technology, SQL injection and XSS correlation engines, and detection of HTTP protocol violations, SecureSphere identifies zero-day attempts to exploit web application vulnerabilities. In addition, once a new vulnerability is published, the Imperva Application Defense Center (ADC) quickly develops a signature or a set of policies to virtually patch the vulnerability. Through automatic security updates, all SecureSphere appliances receive the latest security content and are protected against newly published vulnerabilities. Using SecureSphere, an organization can ensure their web servers are protected against attacks, even before the attack is conceived, developed, and executed. SecureSphere on AWS Test Drive 33

SecureSphere WAF Test Drive FAQ Q: If I don t have RDP access from my network, how can I try a Test Drive? A: You can launch a free Windows workstation with your own AWS account. Alternatively, you can try the Test Drive from a different internet connection if you aren t able to access RDP. Also, check your local firewall to make sure you re allowed to use RDP Protocol. Q: If I didn t finish the Test Drive, can I try it again? A: Yes, you can try a Test Drive up to 3 times. Q: If I don t port 8083 from my network, can I access the Manager (MX)? A: Yes, you can use the Attacker s Workstation to access the MX. Q: Where can I learn more? A: For the latest research and thought leadership, visit the White Papers & ebooks page on Imperva.com. SecureSphere on AWS Test Drive 34

Copyright Notice 2014 Imperva, Inc. All Rights Reserved. Follow this link to see the SecureSphere copyright notices and certain open source license terms: https://www.imperva.com/sign_in.asp?returl=/articles/reference/securesphere-license-and-copyright- Information. This document is for informational purposes only. Imperva, Inc. makes no warranties, expressed or implied. No part of this document may be used, disclosed, reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language in any form or by any means without the written permission of Imperva, Inc. To obtain this permission, write to the attention of the Imperva Legal Department at: 3400 Bridge Parkway, Suite 200, Redwood Shores, CA 94065. Information in this document is subject to change without notice and does not represent a commitment on the part of Imperva, Inc. The software described in this document is furnished under a license agreement. The software may be used only in accordance with the terms of this agreement. This document contains proprietary and confidential information of Imperva, Inc. This document is solely for the use of authorized Imperva customers. The information furnished in this document is believed to be accurate and reliable. However, no responsibility is assumed by Imperva, Inc. for the use of this material. TRADEMARK ATTRIBUTIONS Imperva and SecureSphere are trademarks of Imperva, Inc. All other brand and product names are trademarks or registered trademarks of their respective owners. PATENT INFORMATION The software described by this document is covered by one or more of the following patents: US Patent Nos. 7,752,662, 7,743,420, 7,640,235, 8,024,804, 8,051,484, 8,056,141, 8,135,498 and 8,181,246. Imperva Inc. 3400 Bridge Parkway, Suite 200 Redwood Shores, CA 94065 United States Tel: +1 (650) 345-9000 Fax: +1 (650) 345-9004 Website: http://www.imperva.com General Information: info@imperva.com Sales: sales@imperva.com Professional Services: consulting@imperva.com Technical Support: support@imperva.com SecureSphere on AWS Test Drive 35

Contacting Imperva Headquarters 3400 Bridge Parkway, Suite 200 Redwood Shores, CA 94065 United States Tel: +1 (650) 345-9000 Fax: +1 (650) 345-9004 General Information: info@imperva.com Sales: sales@imperva.com Professional Services: consulting@imperva.com Imperva Sales: (866) 926-4678 (US Only) Technical Support: (877) 467-3780 (650) 345-9000, option 2. Technical Support: support@imperva.com Partners: partners@imperva.com Media Relations: media@imperva.com Investor Relations: ir@imperva.com For questions relating to the Test Drive, please email tm-aws-testdrive@imperva.com SecureSphere on AWS Test Drive 36