Free/Open Source DAST Scanner Comparison - October 2019

Introduction

There are a lot of reviews and comparisons of DAST/Active web scanners out there, but there are very few of them have a detailed, data-driven approach that can give people an idea which scanner(s) to choose. (I still strongly recommend using multiple scanners.) The primary source for DAST scanner comparisons seems to be sectoolmarket.com. I think that this comparison is a good start, but I have two concerns:

1. One, DAST/active scanners generally don't find 100% of vulnerabilities, leading me to believe that the tests themselves aren't as thorough as they ought to be.
2. Two, some vulnerabilities are easier to find than others, and this comparison doesn't distinguish between them.

I've decided, therefore, to do our my research and publish it, but also hopefully give you enough detail where you can evaluate my results and make up your own minds or recreate the results for yourself.

Methodology

I ran all scans against this intentionally vulnerable website, which I've built for comparisons like this one. This website is designed to have a large number of pages with a small number of vulnerabilities on each page, with descriptions of those vulnerabilities visible to anyone who looks at the page. I have tried to add a mixture of scenarios in which a programmer provides no protection at all to attacks with scenarios in which a programmer attempted partial protection to various attacks. I have also tried to create a mixture of scenarios that would be easy for a scanner to find and those that would be difficult. (If you can think of others, please feel free to let us know or make the change and create a pull request. I plan on doing a commercial scanner comparison at some point and will redo these comparisons periodically.)

I have done my best to make clear in these results when a scanner missed something that should have been found or when a scanner found something that I expected it to miss.

The site was hosted in IIS 10, run on Windows 10, and uses a SQL Server 2017 backend. With the exception of W3af, all scanners were also run in Windows.

Scanner Choice

I chose scanners using the following criteria:

• The scanner must be available for free on an ongoing basis. And by "free", I mean free for a company to use for internal purposes. Some free scanners are not free for resale use (i.e. are not free for us to provide in the portal to you), but they are included anyway. Trial versions of paid scanners are not included.
• The scanner must be a broad-attack web scanner. Single vulnerability type scanners like Sqlmap have been excluded from this comparison.
• The free version of the scanner must have the ability crawl and attack a website with a single action. Some vendors, such as Portswigger, have paid versions that do this and free versions that don't. In this particular evaluation I am looking at free versions only, but I hope to do a similar comparison on commercial scanners in the future, at which paid scanners like Burp Suite will be included.)
• The scanner must have been updated relatively recently. For example, Skipfish has a lot of things going for it, but it hasn't been updated in 8 years, so it's probably safe to say that the scanner has been abandoned.
• I've also tried to avoid scanners that have little-to-no usage. While I realize that scanner popularity isn't necessarily a predictor for its quality, I do wish to focus our time evaluating products that people want to use.

In short, I've tried not to spend a lot of time on abandoned or unpopular products. Yes, there are some judgement calls. For instance, neither Vega nor Arachni have been updated in three years, but I've included Arachni but not Vega because of Arachni's popularity. I can, of course, include others as well if there are any I've missed. Please contact me if you'd like to make a case for an additional scanner to be included in this analysis.

Scan Configuration

In general, each scan was configured with as close to an "install, start, push go" setup as possible. While it would be nice to be able to compare "best possible" results from each scanner, doing so is prohibitively difficult. To keep things consistent, I've installed the software, tried to run a scan, then made minimal adjustments until I've gotten what looks like a legitimate scan. Any adjustments that I needed to make will be noted in each scanner's report.

When possible, I've run the scans from a GUI if available (and functional), but the command line if not.

Vulnerabilities

My website has a wide variety of vulnerabilities, each marked with a difficulty of Very Low to Very High. A complete list is available at the end of the report. Here's a breakdown of what I mean by each difficulty:

• Very Low: This is a simple, straightforward problem that a scanner should easily find.
• Low: Most scanners should find most of these.
• Medium: A good scanner probably should be able to find this, but there is some twist to the vulnerability that makes it harder to find.
• High: I believe that it is possible for a scanner to find this, but I'll be surprised if they do.
• Very High: This is difficult or impossible for an automated scanner to exploit this. I will include it in our test in case I'm wrong.

Not all scanners look for each type of vulnerability. I don't make a special note of that in the research — I'm focused on what scanner can do the best job on our sites, not which scanner meets its own specifications the best.

Overall Findings

But before I dig too far into the findings of individual scanners, I should note how the scanners did overall. Of the 120+ vulnerabilities I was hoping the scanners would find, only two were found by all 5 scanners, and nearly a third of the vulnerabilities (41) weren't found by any of the scanners. Here is a summary:

The scanners did best at finding XSS issues, and several scanners did a pretty good job at finding SQL injection issues. I was surprised at how poorly some of the scanners found obvious configuration issues, such as missing headers or the fact that the site didn't use any encryption, and generally none of the scanners were able to find common but harder-to-find issues like business logic abuse. I'll explore this in a little more detail in the Conclusion section.

Arachni

Arachni is one of the more popular free scanners available, despite the fact that it hasn't been updated in three years. Arachni can be run several different ways, including through a GUI and a command line. After installation, I got the GUI working quite easily. One thing worth noting: I had trouble both here and in the past with Arachni spending an inordinate amount of time scanning one page. It frequently will find the same vulnerability on the same page dozens or hundreds of times, causing the scan to run indefinitely. To get around that problem here, I had to set the "scope page limit" to 5.

Scan Completion Time: 5 hours, 24 minutes

Arachni did pretty well with finding SQL Injection and Cross-Site Scripting vulnerabilities, finding most of the vulnerabilities in these categories. It also did a (relatively) good job finding issues with misconfigured cookies and obvious authentication page issues. There are three other items worth mentioning with the scan:

1. Almost half (29 out of 64 findings) were reported multiple times as separate issues, significantly inflating the counts of findings in the report. While not necessarily a problem, it does mean that someone reading an Arachni report has to remove a large number of duplicates before doing anything with the information.
2. On first glance, Arachni did a good job of finding most of the CSRF token issues. But if you look more carefully at the results, you'll notice that Arachni had several false positives around bad CSRF tokens. It's likely that Arachni hasn't been updated to understand the newer .NET Core tokens, and therefore these were falsely flagged. Because of this uncertainty, I have excluded any CSRF findings from all counts from all scanners.
3. Our website had two file uploads: one that was relatively well protected and one that allowed users to upload any file at any time. Arachni flagged the safe one as a potential vulnerability and ignored the poorly-implemented one. On the plus side for Arachni: it is the only scanner to find the file upload. On the minus side: flagging the good one and ignoring the bad one seems odd at best.

Qualys

Qualys is perhaps best known for its server vulnerability scanning, but it does have two types of web scanners — one that looks for malware and a traditional DAST/Active scanner. It also has a free tier which allows unlimited scans, albeit against only one website. (You can delete the website and reconfigure another if you wish to scan multiple websites using the free tier.)

It's worth noting that their product is cloud only. If you wish to scan websites behind a firewall, you have the ability to do so, just not within the free tier.

Scan Completion Time: 58 minutes

Overall, Qualys did much better at finding configuration issues than the other scanners. Its ability to find SQL injection vulnerabilities was average, and its ability to find XSS vulnerabilities was much below average.

Qualys had several false positives. I have several pages that use URL components as search parameters, as is common in REST. Qualys treated these like folders, which meant that its attempts to find files resulted in searches done by the website, which resulted in Qualys thinking that path-based vulnerabilities existed. (Both a found file and the search resulted in the same response — 200 OK — which probably confused the scanner.) In general, I would prefer to have too many vulnerabilities, and it would be difficult for any scanner to differentiate between an insecure file and a valid search, but it was still disappointing that Qualys didn't see the pattern and realize that not ALL of the files it was "finding" were valid.

It is worth noting that you can import findings from Portswigger's Burp Suite into Qualys. This gives you the ability to have Burp's scanning capabilities, which are quite good, within Qualys' management platform (along with their other types of scanners).

Wapiti

Wapiti seems to be the least-known scanner in this report. It is only available as a command-line tool and has quite a bit less flexibility than the other tools here. It seems to have a loyal following, so I've included it in this study.

Scan Completion Time: About 6 hours

The scanner did moderately well in detecting SQL injection attacks. While it didn't find absolutely everything, it found several items that only it and Arachni found. Its ability to find configuration issues, however, leaves much to be desired.

Wapiti's ability to detect XSS vulnerabilities probably isn't quite as good as these results suggest. Yes, Wapiti had detected XSS vulnerabilities on most of my pages, but they did so by using the same approach for each page – with an injected <object> element. In order to better assess scanners' ability to get around XSS defenses that filter specific elements, I will remove the child <param> element the next time I do this assessment, which will likely reduce Wapiti's ability to detect XSS injections on the pages explicitly attempt to block the <object> element.

It is also worth noting that for 19 of the findings Wapiti reported, instead of reporting each finding just once, it reported each of these findings 38 times. This led to a grossly exaggerated total count of vulnerabilities within the report and a large amount of noise a security person would need to sort through to analyze results from a Wapiti scan.

W3af

W3af is a Linux-only scanner that has command-line, API, and GUI versions in its source code. It is extremely flexible and configurable.

I am sorry to say that this scanner is extremely difficult to install and use. Once you download the source code, you need to go through steps to install specific versions of more than a dozen code libraries, some of which has undocumented dependencies that you need to find yourself. The GUI version of the product is dependent upon a library that doesn't seem to have been available since 2016, and I never did get it running. The command line tool is inconsistent and poorly documented, so once you've spent several days getting it running expect to spend several hours getting used to the tool. Oh, and several actions resets some of your settings, so if you do use this tool, look into automating configuration to avoid lots of tedious manual work.

It is worth noting that W3af uses Python 2.7, which will lose support in a very short time. Note: since the writing of this post, support has ended. If it is not upgraded to a supported language, I may exclude this scanner from subsequent analyses.

One last note about the scanner itself — both in this scan and in previous tests the only way I was able to get any results worth seeing I had to use a third-party proxy (the free version of Burp Suite works just fine) for the scanner.

Scan Completion Time: 1 hour, 6 minutes

For all the work that it took to get W3af installed, configured, and get a successful scan, the payoff was underwhelming. W3af's XSS detection was below average but not terrible, but the SQL injection detection left much to be desired.

ZAP

ZAP is a product from the Open Web Application Security Project (OWASP), and is quite popular in the security world. Its main benefits are that it's easy to install, and compared to other low-priced scanners it is relatively easy to use. On top of that, there are many open source plugins that can be used with the tool (though not in this assessment) to enhance its capabilities.

Scan Completion Time: 10 minutes

For all of the attention ZAP gets, its results were generally below average. In particular, its SQL injection detection was significantly below average. It did, however, do a better job at detecting header issues than most of the other scanners evaluated here. And at easily the fastest scan time, it may be the best scanner of these to use in an automated CI/CD pipeline.

One note about its XSS detection — as alluded to with the Wapiti scan, I have about 10 pages that are vulnerable to DOM element injection, but filter out different elements to simulate an incomplete manual filtering done by a programmer. ZAP found the XSS vulnerability on one, but only one, of these pages — apparently submitting an image tag with JavaScript to check for vulnerabilities. One could reasonably make the argument that a developer probably wouldn't filter input by HTML element tag name like I did, so the ZAP results should be better on a real-world site. I would argue, though, that if ZAP wanted to take this approach, they should have chosen a less common element than the <img> tag. Either way, it's likely that ZAP would do a better job finding XSS vulnerabilities on a "real" site than these numbers imply.

Conclusions

Of the scanners here, Arachni seems to be the most complete scanner that found the most vulnerabilities, though the lack of recent updates are troubling. If you don't want to use a single scanner, I would recommend using multiple scanners — you might get pretty good results running a combination of Qualys and Wapiti. (Commercial scanners are, of course, an option too.) And in general, there seems to be a correlation between scan time and result quality – the two scanners with the most findings took the longest time to complete.

Overall, it appears that all of these scanners have a lot of room to improve if they should wish. Aside from missing several items that I feel that they should have found, none of the scanners found any of the business logic (storing "secret" values in hidden fields, following a step-by-step cart process, knowing that the admin section wasn't secret or protected) flaws that I put in. While these issues still present in these scanners, though, our recommendation remains the same: DAST/Active scanners should remain a part of your overall security toolkit, but it should not be your only means for finding issues. SAST/Code scanners, component scanners, manual penetration tests, web application firewalls, vulnerability scanners, and many other tools and approaches should still be on your radar to help you keep safe. No single tool can do it all!

One last request: I would like to do a similar research project involving all the major commercial scanners out there. Please contact me if you would like to get involved!

Appendix: All Results

Page	Vulnerability	Difficulty	Arachni	Qualys	Wapiti	W3af	ZAP
/admin	An "admin" section should be protected via authentication	Medium		Y
/admin	The admin section is easily found because it is added to robots.txt	Low	Y
/admin/*	Pages do not check user role before showing information	Medium
/admin/AllUsers	Page shows username and passwords for all users in the system	Low
/admin/ViewAllOrders	Page shows credit card numbers in plain text	Low
/api/SearchFoods	Page returns stack trace if error occurs	Very Low		Y
/authonly/confirm	All values on the page are editable via hidden fields by hackers	Low
/authonly/confirm	Page has anti-CSRF token, but it is not validated on the server	Medium	Y
/authonly/confirm	Page shows sensitive information (credit card number)	Very Low
/authonly/orderdetail	Page does not verify whether a user can see an order before showing information	High
/authonly/pay	Page does not ensure that the order ID is associated to the user	High
/authonly/pay	Page does not verify whether an order is completed before asking for payment	Very High
/authonly/pay	Page sends sensitive information via query string to the next page	Very Low
/authonly/shop	Page calculates price based on values passed in hidden fields that can be changed by hackers	Low
/authonly/shop	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/authonly/sqli	Query string parameter is vulnerable to SQL injection attacks	Very Low	Y (3)		Y (2)		Y
/authonly/storedsqli	Page is vulnerable to stored SQL injection attacks	Medium
/authonly/storedxss	Page is vulnerable to stored XSS attacks	Medium
/authonly/unsafefileupload	Error shown on page	Medium					Y
/authonly/unsafefileupload	Page allows file uploads without checking contents/format, etc.	Medium
/authonly/unsafefileupload	Page uploads are stored within the file root	Very High
/authonly/viewmyorders	Page takes a user ID from the query string but does not verify that this is the logged in user	High
/authonly/xss	Query string parameter is vulnerable to XSS attacks	Very Low	Y (3)		Y		Y
/Identity/Account/Login	admin/password is a set of common (and unsafe) credentials and is a user in the site	Very Low
/Identity/Account/Login	Auth cookie(s) still work if user logs out	Low
/Identity/Account/Login	Encrypted password stored as insecure cookie	Very Low
/Identity/Account/Login	Encrypted password stored with hard-coded (and constant) key and IV	Medium
/Identity/Account/Login	Information leakage - incorrect username has different message than incorrect password	Medium
/Identity/Account/Login	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (5)
/Identity/Account/Login	Page is not protected via SSL	Very Low		Y (2)
/Identity/Account/Login	Password encrypted with insecure algorithm	Medium
/Identity/Account/Login	Password field has autocomplete turned on	Very Low	Y	Y		Y
/Identity/Account/Login	Password field sent in plain text	Very Low	Y (6)
/Identity/Account/Login	Password stored as insecure cookie	Very Low					Y
/Identity/Account/Login	Unvalidated redirect after user logs in	Low
/Identity/Account/Login	Username stored as insecure cookie	Very Low	Y				Y
/Identity/Account/Logout	Unvalidated redirect after user logs in	Medium				Y
/Identity/Account/Register	Password field sent in plain text	Low	Y (8)	Y
/Identity/Account/Register	Password field has autocomplete turned on	Low	Y	Y		Y
/Identity/Account/Register	Password is stored in an insecure cookie	Very Low		Y
/Identity/Account/Register	Username stored as insecure cookie	Very Low		Y
/Miscellaneous/AngularJS	Page unsafely adds text which can be rendered by the AngularJS engine	Low
/Miscellaneous/AngularJS	Page uses an unsafe version of AngularJS	Medium		Y
/Miscellaneous/ConnectionString	A connection string (with password) is included in the comments behind the page	Very Low
/Miscellaneous/CSSInjection	Page has anti-CSRF token, but it is not validated on the server	Medium					Y
/Miscellaneous/CSSInjection	Page unsafely includes form data within CSS on the page	Medium
/Miscellaneous/FileInclusion	Page has anti-CSRF token, but it is not validated on the server	Medium					Y
/Miscellaneous/FileInclusion	Page is vulnerable to local file inclusion attacks	Very Low	Y	Y	Y (2)		Y
/Miscellaneous/JSInjection	Page unsafely includes query string text within script on the page	Low		Y (2)	Y	Y	Partial
/Miscellaneous/MD5	Page adds a cookie with a value hashed with an unsafe hash	Medium
/Miscellaneous/MD5	Page adds misconfigured cookie to the page	Very Low	Y	Y
/Miscellaneous/MD5	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/Miscellaneous/ValueShadowing	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/Miscellaneous/ValueShadowing	Page is vulnerable to value shadowing	Medium
/Miscellaneous/Xxe	Page has anti-CSRF token, but it is not validated on the server	Medium
/Miscellaneous/Xxe	Page returns an XML to the server for processing and is vulnerable to XXE attacks	Very Low
/Miscellaneous/Xxe	The "Search For" parameter is vulnerable to SQL injection attacks	High	Y
/sql/*/AllStringWithinPath	Middle "folder" in path is vulnerable to string-based SQL injection attacks	Medium
/sql/AllIntInForm	Anti-CSRF token present but not validated	Medium	Y (2)
/sql/AllIntInForm	Form value is vulnerable to integer-based SQL injection attacks	Very Low	Y	Y		Y
/sql/AllIntInQS	Integer comparison SQL injection vulnerability from query string	Very Low	Y	Y	Y
/sql/AllIntInQSQuoteEscaped	Query string value is sent to database in integer comparison, but quotation marks are escaped	High	Y	Y	Y
/sql/AllStringInForm	Anti-CSRF token present but not validated	Medium	Y (2)
/sql/AllStringInForm	Form value is vulnerable to string-based SQL injection attacks	Very Low	Y	Y	Y (38)
/sql/AllStringInFormCsrfProtected	Form value is vulnerable to string-based SQL injection attacks	Low	Y		Y (38)
/sql/AllStringInPath	Last "folder" in path is vulnerable to string-based SQL injection attacks	Low
/sql/AllStringInQS	String-based SQL injection vulnerability from query string	Very Low	Y	Y	Y
/sql/AllStringInQSQuoteEscaped	Query string value is sent to database, but quotation marks are escaped	Very High
/sql/AllStringLineBreak	"Food Group" parameter is vulnerable to SQL injection attacks	Very Low	Y	Y	Y (38)
/sql/AllStringLineBreak	"Food Name" parameter is vulnerable to SQL injection attacks	High	Y	Y	Y (38)
/sql/AllStringLineBreak	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/sql/AllStringLineBreakSafeSecond	"Food Name" parameter is vulnerable to SQL injection attacks	High	Y		Y (39)
/sql/AllStringLineBreakSafeSecond	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/sql/ErrorBased	"Food Name" parameter is vulnerable to SQL injection attacks	Very Low	Y (2)	Y (2)	Y (2)		Y
/sql/ErrorBased	Page shows full error messages and stack trace if an error occurs	Very Low
/sql/FalsePostive_Calc	Page runs a calculation on the query string value	High
/sql/QueryStringKey	Query String Key is vulnerable to string-based SQL injection attacks	Very High
/sql/UrlDecode	Query string parameter is vulnerable to double encoded SQL injection attacks	High	Y
/sql/UrlDecodeInForm	Form parameter is vulnerable to encoded SQL injection attacks	Medium
/sql/UrlDecodeInForm	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/AllowAudio	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/AllowAudio	XSS filtering ignores audio tag	High	Y		Y (38)
/xss/AllowBody	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/AllowBody	XSS filtering ignores body tag	High	Y		Y (38)
/xss/AllowIFrame	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/AllowIFrame	XSS filtering ignores iframe tag	High	Y		Y (38)
/xss/AllowImg	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/AllowImg	XSS filtering ignores img tag	Medium			Y (38)		Y
/xss/AllowMarquee	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/AllowMarquee	XSS filtering ignores marquee tag	High	Y		Y (38)	Y
/xss/AllowMixedCase	Form value removes tags to prevent XSS attacks but is case sensitive	Medium	Y		Y (38)
/xss/AllowMixedCase	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/AllowObject	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/AllowObject	XSS filtering ignores object tag	High	Y		Y (38)
/xss/AllowSlash	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/AllowSlash	XSS filtering cannot handle tags with slashes instead of spaces	High	Y		Y (38)
/xss/AllowSvg	XSS filtering ignores svg tag	High	Y		Y (38)
/xss/AllowUpperCase	Form value removes tags to prevent XSS attacks but is case sensitive	Low	Y		Y (38)	Y
/xss/AllowUpperCase	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/AllowVideo	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/AllowVideo	XSS filtering ignores video tag	High	Y		Y (38)
/xss/InputEncoded	Input value is vulnerable to value shadowing	Medium
/xss/InputEncoded	Page has anti-CSRF token, but it is not validated on the server	Medium					Y
/xss/InputEncoded	User input is partially encoded and is unsafely added to an input attribute	Medium	Y			Y	Y
/xss/InputNoEncoding	Input value is vulnerable to value shadowing	Medium
/xss/InputNoEncoding	Page has anti-CSRF token, but it is not validated on the server	Medium					Y
/xss/InputNoEncoding	User input is unsafely added to an input attribute	Very Low	Y	Y (2)	Y	Y	Y
/xss/Jquery	Form value has some processing to prevent XSS attacks but is still rendered unsafely	Medium
/xss/Jquery	JavaScript/JQuery code unsafely processes user input	Medium	Y
/xss/MetaTag	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/MetaTag	User input is unsafely added to a meta tag	Low	Y		Y (38)		Y
/xss/RecursiveEndBracket	Form value removes tags to prevent XSS attacks but doesn't look for nested tags	Low	Y		Y (38)		Y
/xss/RecursiveEndBracket	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/RecursiveNoEndBracket	Form value removes tags to prevent XSS attacks but doesn't look for nested tags	Very Low	Y		Y (38)
/xss/RecursiveNoEndBracket	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
/xss/ReflectedFromQS	Query string value is rendered on the page unsafely	Very Low	Y (3)	Y (3)	Y	Y	Y
/xss/UrlDecode	Form value ignores URL encoded characters, then decodes content	Low
/xss/UrlDecode	Page has anti-CSRF token, but it is not validated on the server	Medium	Y (2)
Home/Global	Content Security Policy missing	Low		Y
Home/Global	Cross-Domain Script Include	Low		Y			Y (20)
Home/Global	Disabling Content Type sniffing (X-Content-Type-Options)	Very Low		Y			Y (20)
Home/Global	Frameable Response (Missing X-Frame-Options header)	Very Low	Y	Y (10)		Y	Y (20)
Home/Global	No SSL Certificate used/available	Very Low		Y
Home/Global	Server Header	Low		Y		Y
Home/Global	Site uses a vulnerable version of bootstrap	Medium
Home/Global	Site uses a vulnerable version of jquery	Medium		Y
Home/Global	X-Permitted-Cross-Domain-Policies missing	Low
Home/Global	X-XSS-Protection	Very Low		Y			Y (20)