Dear WAFEC readers and contributors

I'm Erwin Huber - Head of R&D Web Application Security at Ergon Informatik AG.
Ergon is the vendor of the web application firewall Airlock. WAFs have been the
core of my professional life for the last 10 years.

My post comes in the last minute - since I didn't realize, that wafec 2 was
growing. Sorry for that.

I appreciate the new approach for the document a lot. To focus on benefits
rather than internas is a userfriendly approach.

In chapter 2.2 I suggest the following new Use Cases:
2.2.5 Authorization and Authentication
2.2.6 Architecture Masking
2.2.7 Data Leakage Prevention

Authorization and authentication is a relevant part of the "swiss-style" WAFs.
This is not only Airlock but also Nevis Proxy from Adnovum and Secure Entry
Server from United Security Providers. Its a good filtering technique to check
the users first if you know that only well known users are allowed on a system.
Airport security does the same thing.

Architecture masking is a benefit that reverse proxy are bringing. There is
no information about what logic is implemented on which back-end system.

Today's WAFs (including Airlock) are not good in Data Leakage Prevention. But I
think an organisation has an interest in defining types of data which must not
leave the perimeter (e.g. unmasked credit card numbers).
Web applications are not the only path infromation can leave a system - so I'm
not sure but it's at least worth discussing the issue.

2.3 Minimum Requirement
I don't think this is very useful. The minimum highly depends on the needs and
the use case. As a common minium I see "do something more than a traditional
firewll on http/https checks". I just don't see the point.

3.3.1 Positive Security
What is the meaning of "URL rewrite and REST interface support"?

I propose as additional content in the paragraph "generic positive security" -
this might include automated general protection techniques such as cookie
protection, form parameter signatures, url encyrption/signing (workflow
binding, anti forceful browsing, anti csrf), declarative whitelisting (the
back-end application defines characteristics of parameters - such as pattern
in web forms 2.0).

3.3.5 Session Tracking
I propose the additional content "client fingerprinting".

I propose the additional paragraphs:
3.3.6 Content Modification
for DLP, hiding of error pages, ...
3.3.7 Upstream Authentication

4.3.2 Authentication Support
I'm astonished about the mention of NTLM. For me its a bug not a feature to
allow NTLM authentication on a public accessible server. NTLM relaying is a
known real problem for more than 10 years. Even MS says "do not use NTLM".
Zack Fasel presented his "ZackAttack" Tool on BlackHat 2012:
https://github.com/zfasel/ZackAttack
A good WAF must have the ability to prevent NTLM authentication - not allow
it.

I propose the additional paragraphs:
4.3.3 Application Monitoring and Load Balancing
Monitor the health state of a back-end server and take measurements
(display not-available page, switch to another server instance, ...)

Defining more than one back-end host providing the same content allows an
SSL endpoint (such as reverse proxy) session-aware load balancing. All requests
for the same user session are reliable on the same back-end system.

5.1 Managment
Why is there no mention for "web interface"?

6.1 Non-technical Criteria
(just a typo in the title)

I'd be more than happy to provide content for the additional sections I propose
above.

Any thougths / comments on my propositions?

best regards
erwin

Hi Erwin,

The document I shared is only an outline. I included some text to make the sections intention more clear but there are in no way comprehensive. The people volunteering to write the different sections will fill them in and I am sure would take into consideration your input.

To that end: do you want to take one of the remaining chapters to write? Should I list you on the contributors page (http://projects.webappsec.org/w/page/54150727/WAFEC%202)

I do have a few of your remarks outside of the context of a specific chapter:

• We regard to your additions to the use cases chapter: we had a discussion about what to include in the definition and use cases for a WAF . This is not an easy subject and also prone to vendor bias (for each vendor the functionality they provide is a WAF). The decision was to be restrictive to application protection as described in chapter 3 (which itself is still not written). As other features can be very beneficial to the customer as well, even for security, we decided to include all those in an appendix (6.1, "Integrated functionality"). In this framework, each of the additional features you suggest (Authorization and Authentication, DLP, Architecture masking, load balancing and application monitoring are those I notices) should find their place in either section 3.3 if they offer a protection technique or in section 6.1 if they are complementary and of value but do not cover a threat.

• Minimum requirements is indeed a challenging section, however I think it is important. Otherwise you will find that any IPS or network firewall can be labeled as a WAF (or an Espresso Machine :-))

• Section 4.3 address compatibility with web applications rather than addition features for application delivery.

~ Ofer

-----Original Message-----
From: Erwin Huber [mailto:erwin.huber@ergon.ch]
Sent: Thursday, November 15, 2012 11:58 AM
To: Ofer Shezaf
Cc: wasc-wafec@lists.webappsec.org
Subject: WAFEC 2 outline

Dear WAFEC readers and contributors

I'm Erwin Huber - Head of R&D Web Application Security at Ergon Informatik AG.
Ergon is the vendor of the web application firewall Airlock. WAFs have been the core of my professional life for the last 10 years.

My post comes in the last minute - since I didn't realize, that wafec 2 was growing. Sorry for that.

I appreciate the new approach for the document a lot. To focus on benefits rather than internas is a userfriendly approach.

In chapter 2.2 I suggest the following new Use Cases:
2.2.5 Authorization and Authentication
2.2.6 Architecture Masking
2.2.7 Data Leakage Prevention

Authorization and authentication is a relevant part of the "swiss-style" WAFs.
This is not only Airlock but also Nevis Proxy from Adnovum and Secure Entry Server from United Security Providers. Its a good filtering technique to check the users first if you know that only well known users are allowed on a system.
Airport security does the same thing.

Architecture masking is a benefit that reverse proxy are bringing. There is no information about what logic is implemented on which back-end system.

Today's WAFs (including Airlock) are not good in Data Leakage Prevention. But I think an organisation has an interest in defining types of data which must not leave the perimeter (e.g. unmasked credit card numbers).
Web applications are not the only path infromation can leave a system - so I'm not sure but it's at least worth discussing the issue.

2.3 Minimum Requirement
I don't think this is very useful. The minimum highly depends on the needs and the use case. As a common minium I see "do something more than a traditional firewll on http/https checks". I just don't see the point.

3.3.1 Positive Security
What is the meaning of "URL rewrite and REST interface support"?

I propose as additional content in the paragraph "generic positive security" -
this might include automated general protection techniques such as cookie
protection, form parameter signatures, url encyrption/signing (workflow
binding, anti forceful browsing, anti csrf), declarative whitelisting (the
back-end application defines characteristics of parameters - such as pattern
in web forms 2.0).

3.3.5 Session Tracking
I propose the additional content "client fingerprinting".

I propose the additional paragraphs:
3.3.6 Content Modification
for DLP, hiding of error pages, ...
3.3.7 Upstream Authentication

4.3.2 Authentication Support
I'm astonished about the mention of NTLM. For me its a bug not a feature to
allow NTLM authentication on a public accessible server. NTLM relaying is a
known real problem for more than 10 years. Even MS says "do not use NTLM".
Zack Fasel presented his "ZackAttack" Tool on BlackHat 2012:
https://github.com/zfasel/ZackAttack
A good WAF must have the ability to prevent NTLM authentication - not allow
it.

I propose the additional paragraphs:
4.3.3 Application Monitoring and Load Balancing
Monitor the health state of a back-end server and take measurements
(display not-available page, switch to another server instance, ...)

Defining more than one back-end host providing the same content allows an
SSL endpoint (such as reverse proxy) session-aware load balancing. All requests
for the same user session are reliable on the same back-end system.

5.1 Managment
Why is there no mention for "web interface"?

6.1 Non-technical Criteria
(just a typo in the title)

I'd be more than happy to provide content for the additional sections I propose
above.

Any thougths / comments on my propositions?

best regards
erwin

Hi Ofer

Thank you for your explanations.

I understand the neutrality vs. vendor conflict - I think there is no "real" objective view. Anyone has its own use cases and own solutions in mind - whether he is a vendor, a user of some concrete implementations or a consultant which likes some concepts and dislikes others.

When I have a look at the use cases ("Logging and Troubleshooting", "Attack Detection", "Attack Mitigation" and "Virtual Patching") then I think: why is "Virtual Patching" a use case for its own? Isn't it a specialized attack mitigation? The difference in virtual patching is, that you know exactly what vulnerability the application has. In general mitigation you don't have to know that. In my eyes Authentication is a real "other" security use case not just a specialized use case. I won't insist on that - just my thoughts.

I see the argumentation of "minimum requirements" - yes an Espresso Machine must not be mistaken as a WAF ;-) Good argumentation. I think the differenciation should go into the "2.1 Definition". I understand a "definition" as more specific than minimal requirements. What would be written in one paragraph what doesn't fit in the other? There is a risk of writing twice the same in different words.

OK, security features are placed i n3.3 - other features in 6.1. The outline draft mentions "6.1 Non-Technical Criteria". The non-technical criteria are important - I would not skip that. So there is another 6.1 chapter? Since features are a technical criteria.

I volunteer to write the appendix "Additional Features", "Alternative and Complementary Solutions", "Non-technical criteria". In the moment I can't estimate "Testing Framework" and "Suggested Weighting Schemes". Maybe it's also possible for me to do - can you explain the ideas?

erwin

----- Original Message -----
From: "Ofer Shezaf" ofer@shezaf.com
To: "Erwin Huber" erwin.huber@ergon.ch
Cc: wasc-wafec@lists.webappsec.org
Sent: Thursday, November 15, 2012 9:21:38 PM
Subject: RE: WAFEC 2 outline

Hi Erwin,

The document I shared is only an outline. I included some text to make the sections intention more clear but there are in no way comprehensive. The people volunteering to write the different sections will fill them in and I am sure would take into consideration your input.

To that end: do you want to take one of the remaining chapters to write? Should I list you on the contributors page (http://projects.webappsec.org/w/page/54150727/WAFEC%202)

I do have a few of your remarks outside of the context of a specific chapter:

• We regard to your additions to the use cases chapter: we had a discussion about what to include in the definition and use cases for a WAF . This is not an easy subject and also prone to vendor bias (for each vendor the functionality they provide is a WAF). The decision was to be restrictive to application protection as described in chapter 3 (which itself is still not written). As other features can be very beneficial to the customer as well, even for security, we decided to include all those in an appendix (6.1, "Integrated functionality"). In this framework, each of the additional features you suggest (Authorization and Authentication, DLP, Architecture masking, load balancing and application monitoring are those I notices) should find their place in either section 3.3 if they offer a protection technique or in section 6.1 if they are complementary and of value but do not cover a threat.

• Minimum requirements is indeed a challenging section, however I think it is important. Otherwise you will find that any IPS or network firewall can be labeled as a WAF (or an Espresso Machine :-))

• Section 4.3 address compatibility with web applications rather than addition features for application delivery.

~ Ofer

-----Original Message-----
From: Erwin Huber [mailto:erwin.huber@ergon.ch]
Sent: Thursday, November 15, 2012 11:58 AM
To: Ofer Shezaf
Cc: wasc-wafec@lists.webappsec.org
Subject: WAFEC 2 outline

Dear WAFEC readers and contributors

I'm Erwin Huber - Head of R&D Web Application Security at Ergon Informatik AG.
Ergon is the vendor of the web application firewall Airlock. WAFs have been the core of my professional life for the last 10 years.

My post comes in the last minute - since I didn't realize, that wafec 2 was growing. Sorry for that.

I appreciate the new approach for the document a lot. To focus on benefits rather than internas is a userfriendly approach.

In chapter 2.2 I suggest the following new Use Cases:
2.2.5 Authorization and Authentication
2.2.6 Architecture Masking
2.2.7 Data Leakage Prevention

Authorization and authentication is a relevant part of the "swiss-style" WAFs.
This is not only Airlock but also Nevis Proxy from Adnovum and Secure Entry Server from United Security Providers. Its a good filtering technique to check the users first if you know that only well known users are allowed on a system.
Airport security does the same thing.

Architecture masking is a benefit that reverse proxy are bringing. There is no information about what logic is implemented on which back-end system.

Today's WAFs (including Airlock) are not good in Data Leakage Prevention. But I think an organisation has an interest in defining types of data which must not leave the perimeter (e.g. unmasked credit card numbers).
Web applications are not the only path infromation can leave a system - so I'm not sure but it's at least worth discussing the issue.

2.3 Minimum Requirement
I don't think this is very useful. The minimum highly depends on the needs and the use case. As a common minium I see "do something more than a traditional firewll on http/https checks". I just don't see the point.

3.3.1 Positive Security
What is the meaning of "URL rewrite and REST interface support"?

I propose as additional content in the paragraph "generic positive security" -
this might include automated general protection techniques such as cookie
protection, form parameter signatures, url encyrption/signing (workflow
binding, anti forceful browsing, anti csrf), declarative whitelisting (the
back-end application defines characteristics of parameters - such as pattern
in web forms 2.0).

3.3.5 Session Tracking
I propose the additional content "client fingerprinting".

I propose the additional paragraphs:
3.3.6 Content Modification
for DLP, hiding of error pages, ...
3.3.7 Upstream Authentication

4.3.2 Authentication Support
I'm astonished about the mention of NTLM. For me its a bug not a feature to
allow NTLM authentication on a public accessible server. NTLM relaying is a
known real problem for more than 10 years. Even MS says "do not use NTLM".
Zack Fasel presented his "ZackAttack" Tool on BlackHat 2012:
https://github.com/zfasel/ZackAttack
A good WAF must have the ability to prevent NTLM authentication - not allow
it.

I propose the additional paragraphs:
4.3.3 Application Monitoring and Load Balancing
Monitor the health state of a back-end server and take measurements
(display not-available page, switch to another server instance, ...)

Defining more than one back-end host providing the same content allows an
SSL endpoint (such as reverse proxy) session-aware load balancing. All requests
for the same user session are reliable on the same back-end system.

5.1 Managment
Why is there no mention for "web interface"?

6.1 Non-technical Criteria
(just a typo in the title)

I'd be more than happy to provide content for the additional sections I propose
above.

Any thougths / comments on my propositions?

best regards
erwin