Maybe you want more details on what Apache as a "reverse proxy" can do, as you already know what ISA Server can do ?
As I've already linked you to modsecurity, let's take a quick look at it(I suppose you don't want to run Apache as reverse proxy butt naked).
I've linked you first the FAQ section because you need to first check something with your web team if you want to proceed on this path:
Building a ModSecurity reverse proxy appliance is a non-trivial task as you need specific skill sets - expert in Apache, web application security, and ModSecurity.
If this check fails, forget about it.
In theory the HTTP requests should be analysed before they get handled by the web server, but in practice some "processing" might be done before it reaches the needed mod.
It can detect protocol violations.
It supports encoding types such as multipart/form-data or application/x-www-form-urlencoded.
It can intercept requests and responses bodies, and can analyze XML payloads.
It can parse cookies(format validation, value normalization).
It uses various normalization operations, and not only normalizes URLs, say if you use path names as input for a HTML form field it can analyze that to avoid evasion.
It is able to "understand" what you have in the back, say php, asp, IIS, Apache, etc., thus to have certain filters on for protection.
It includes conditional execution, say if the transaction payload is XML, it can use a certain set of rules.
It can detect business logic flaws.
It can create more complex conditions using logical operators along with logical expressions.
It can inspect and verify uploaded files.
It has some really good logging capabilities.
Obviously it can do HTTPS filtering.
So as you can see it is able to break the HTTP flow into parts, and analyze them, say headers, requests and responses bodies, parameters, etc.(headers, POST payloads, environment variables, server variables, individual page variables, cookies, scripts output).
It can operate using the negative security mode, the positive security model, extrusion detection model and virtual patching(this one can fall into the negative security model or the positive security model).
It can be used to detect and to prevent attacks or just to detect attacks.
It comes with a free Core Rules set, which is a collection of rules that will detect the most common web attacks. This is a generic set of rules, that will implement a negative security model.
You can develop a positive security model for your something, say OWA, assuming you know how OWA works. Breach has an enhanced set of rules which they say uses a positive security model for OWA.
You may need to do some work to harden the box itself. Much more work than with ISA Server itself. ISA has network layer protection features that modsecurity does not provide as it focuses on something else.
As you can see ISA Server cannot match ModSecurity in certain areas, nor it has to do that, as Microsoft has another solution for that.
You can take a look here:
To be more specific, see what ISA Server, IAG, and Breach(using modsecurity), say can do for OWA:
When it comes down to filtering configuration, ISA server's main "disadvantage"(it may be a harsh word, as it was designed for a specific role, which does not necessarily means this is a disadvantage, and the comparison we make here is not quite fair) is that application protection is mostly based on attack signatures, whitelisting is done on a limited base(for paths, request methods, etc.), and that request and response bodies are not actually getting much inspection, see this example:
Actually, did you looked at this roadmap, two pennies for some sharp eyes:
Get Our ISA 2006 Book!: http://tinyurl.com/2gpoo8