« August 2009 | Main | October 2009 »

7 posts from September 2009

September 30, 2009

The key to successful WAF deployment is getting the ownership right

While pruning my bookmarks, I stumbled across this fantastic post to the Secure Coding mailing list, from almost two years ago:

The first part of the email gives a great insight into PCI. The second part of the email is about web application firewalls, and it's equally interesting, exciting even. This sort of email is extremely important to help understand why web application firewalls aren't nowhere near the popularity as of network-level controls. The main issue is ownership, and almost everyone struggles with it.

Anonymous application security practitioner writes:

7) Web Application Firewalls (WAF) are alluded to in requirement 6.6 of
PCI DSS v1.1 as an "application layer firewall":

6.6 Ensure that all web-facing applications are protected
against known attacks by applying either of the following
methods:
- Having all custom application code reviewed for common
vulnerabilities by an organization that specializes in
application security
- Installing an application layer firewall in front of
web-facing applications.
Note: This method is considered a best practice until June 30, 2008,
after which it becomes a requirement.

Notice that WAF is not required per se, but the alternative of inspecting
all application code by an organization that specialized in application
security is very seldom feasible. In fact, InfoSec first approached our
team to do code inspections, but when we heard that there were more than
1M LOC, we told them that this was impossible given our current team size.

Code inspection *might* work for some small company who exclusively uses
some custom code using CC info with something like a small, custom
a shopping cart application, but it is not going to be economical for
most medium to large companies.

I also think that there is going to be significant push-back by
companies where PCI audits are required. I wouldn't be surprised if that
date gets pushed out to Jan, 2009. On the positive side at least, the
PCI auditor who was interacting with our company said that we could
configure an Apache proxy together with Ivan Ristic's "mod_security"
and that would qualify as a legitimate WAF to satisfy section 6.6.
So at least we can experiment on-the-cheap. (Of course YMMV at other
companies; check with your assigned PCI auditor to see what WAF is
right for you! ;-)

8) I personally have mixed feelings about WAF. Specifically, I have some
anxiety about that app dev teams will start relying on the WAF to
filter out the PCI auditors pen testing attempts rather than on
correcting it within the application itself. I don't have too much of a
problem of using a WAF to address DoS type attacks (6.5.9). (IMO, DoS
attacks are often very difficult to handle within the application itself,
especially when the app itself is using some J2EE container; addressing
DoS at the app level almost always requires some significant amount
of redesign which only complicates the app, making it more likely to
be vulnerable to other vulnerabilities.) However, inevitably some
clever 0-day is going to get past most WAFs, especially if they are
solely signature based. (Those which are also anomaly-based *might* have a
prayer.)

9) The dirty little secret that no one is talking about are the operational
issues with WAF. Our company discussed possible use with WAF/XML firewalls
years before PCI DSS made it "popular".

We never got much beyond initial discussions because we couldn't
identify any existing personnel within our company who had all the
required skills to troubleshoot it AND would be willing to do so.
(Think additional "pager duty".) We talked with stakeholders from
InfoSec, our company's network engineering team who manages our border
firewalls and routers, some *nix and Windows OS system administration
teams, and amongst our team. I think there might be only 2, possibly
3, people who have sufficient skills to operate and troubleshoot a
WAF, and all of those people are smart enough to know that it would be
a thankless job and they aren't really looking for additional opportunities
to carry pagers. Chances are, we would have to probably hire a few people
fully dedicated to this, but even then, there is the question where would
they fit organizationally? One possible option not explored--because we had
no stakeholders represented who could finance such a thing--would be to
outsource the management of WAF to some managed security company such
as BT Counterpane, ISS, etc. Anyhow, it's a big problem and one that
isn't going to go away.

At first, intuition would suggest at first that usual FW teams would be best
suited (and that indeed is what most WAF vendors suggest), but for the most
part, the usual FW teams' understanding of attacks at layer 7 is often
very limited.

If you or anyone you know ever comes up with a solution on how to address
this particular issue, please let me know. I think it is a show stopper.

September 29, 2009

Analysis of Elliptic Curve support in current browsers

In my previous post I mentioned Adrian Dimcev, who helped me get Elliptic Curve detection right, in SSL Labs. He has now posted a detailed analysis of the current support of elliptic curve cryptography across browsers:

I recommend that you read this highly informational post if you have even a slight interest in TLS.

September 22, 2009

SSL Labs: Improved Elliptic Curve and TLS 1.2 detection

The latest version of the SSL assessment software running on SSL Labs features much better detection of the SSL servers that use Elliptic Curve cryptography, TLS 1.1 and TLS 1.2. Windows Server 2008 leads when it comes to these technologies and Microsoft's test server (tls.woodgrovebank.com) demonstrates that very well. Sadly, there's currently no browser that can talk to the Windows Server 2008 in a way that uses all the capabilities that are on offer. Even IE8 has some of the high-end features disabled and gets some others wrong.

I must mention Adrian Dimcev, who pushed me to get this work done. He worked relentlessly to figure out the exact combinations of handshake bits (literally) that produce desired results. I've urged Adrian to describe his findings for everyone to read, and let's hope that he'll do that. In the meantime, his recent blog post provides a bunch of useful information on TLS 1.2.

September 09, 2009

SSL Threat Model

SSL is easy to use but also very easy to use incorrectly. The ecosystem, which is built of the specifications, the implementations, the CAs and the PKI, is full of traps, each of which is very easy to fall into. Once I started to spend significant time thinking about SSL I set out to build a model of the ecosystem, for my own education and to ensure that I understand it all. That's how I arrived to the SSL Threat Model. The image is too big to include here, but just click on the link below to get it:

I do understand that many of the elements in the model need explanations, but the diagram is all I have at the moment. As a matter of fact, the diagram has been sitting in my virtual drawer for months in the hope that I would eventually accompany it with some documentation. But seeing that the documentation is not going to happen any time soon, I decided to go ahead and publish the diagram alone.

Feel free to post comments here, though!

September 04, 2009

Two bugs in mod_sslhaf fixed

I fixed two bugs in mod_sslhaf (my passive SSL fingerprinting module for Apache; see my previous blog post for details), which means that you need to upgrade if you're using it:

  1. Pure SSLv2 access was ignored due to a badly interpreted version number (SSLv2 uses a different byte order).
  2. There was a problem with sites that do not use SSL, which would cause Apache to stall.

Everything seems to be in order now.

September 03, 2009

SSL Labs: a batch of small improvements

I love when a project enters the phase where you're mainly concerned with improving upon what already works! I had some time yesterday and today to spend on SSL Labs so I used the opportunity to tweak the software a bit. The changes are as follows:

  • Successful assessments are now cached for 24 hours.
  • Unsuccessful assessments are now cached for 15 minutes.
  • Display complete certificate chains, and make clear which certificates are trusted.
  • Do more to detect SSLv2 error responses (a polite way for a site to say that it does not support SSLv2).
  • Use colours and tags ("weak", "insecure", "confusing") to point to the bits in a configuration that are bad or can be improved.

I also fixed a bug or two, but that's not very important.

September 01, 2009

Tuning ModSecurity Console on Windows

For the users of ModSecurity, the free ModSecurity Console remains the best choice for the handling and storage of audit log alerts. There's one problem with it, though—the 64 MB of RAM it allocates is too small for a real deployment. The good news is that the memory usage can be tuned, along with a few other things. Ryan wrote about the console tuning before, here and here.

Ryan's advice will help you on a Unix platform, because the shell script that starts the console can be edited, but it doesn't work on Windows because there's no file to edit. On Windows, the console is started through an executable file. It took me some time to find a solution, after someone asked me for advice today.

ModSecurity Console is packaged using install4j, which is a fantastic packaging platform for Java applications. In order to tune the JVM parameters of Windows applications that run as services, simply create a text file that uses the same name as the executable, replacing the .exe extension with .vmoptions. In the case of ModSecurity Console you need to create modsecurity-console.vmoptions alongside modsecurity-console.exe. In the file, just put one JVM option on each line. For example:

-Xms512m
-Xmx1024m

The above configuration will allocate 512 MB to the console at startup, with the option to use up to 1024 MB in total.

MY WORK

IronBee is the next generation web application firewall engine, and it's open source too.
ModSecurity Handbok cover
ModSecurity Handbook is the definitive guide to the world's most popular web application firewall.
Apache Security cover
Apache Security is the complete guide to securing your Apache web server.
SSL Labs offers a comprehensive SSL security assessment consisting of 250+ checks. To start, enter your domain name below:

ABOUT ME

Ivan Ristić is an open source advocate, entrepreneur, writer, programmer and web security specialist. He is the principal author of ModSecurity, the open source web application firewall, and the author of Apache Security, a concise yet comprehensive web security guide for the Apache web server.   [LinkedIn Profile]

My Photo

TWITTER

@ivanristic

    FEEDS