Somewhere, a CIO has just spent millions of dollars on new software licenses for new JEE Application Servers. The DevOps Team hurriedly installs the software, probably feeling crunched by a time deadline. The Software Development Teams hurriedly deploy custom software on top of the newly acquired JEE Container, also pressured by similar time deadlines. All the while, no one has considered the default configuration settings for the new JEE Application Server; many don’t think they even matter. To the contrary, however, Default Application Server Configurations are rarely what your organization wants or needs, especially when it comes to Performance Tuning and Security. Here is one anecdote to help highlight why relying on Commercial Off The Shelf (COTS) Software, ‘Out of the Box’ and with default settings, is a usually a bad idea.
Take IBM’s Websphere 7, for example. With a few simple mouse clicks after installing the software in your Enterprise Environment, the DevOps Team can greatly enhance the security profile of your JEE Application Server when implementing SSL/TLS.
As the SSL suite of protocols age, it is becoming a best-practice to solely implement TLS. For example, many places will want to avoid vulnerabilities to the SSLv3 POODLE attack.
The default configuration for Websphere 7 is to allow both SSL and TLS in-bound (and out-bound) in terms of HTTPS secure channel negotiations.
You could use the configuration screen above to select either all TLS protocols or only the TLS protocol you want to allow. But this may provide a false sense of security. The screen above will only prevent in-bound SSL protocol exchanges for external clients trying to connect to your server. But what if some of the Software Engineers in your organization have written Java HTTPS Client Code, which establishes HTTPS connections with external SOAP or REST Web Services, for example? Will this code be similarly prevented from using SSL in out-bound HTTPS requests? The answer is no.
Given the current Websphere 7 configuration above, custom Java code running in your container will still be allowed to negotiate HTTPS connections using SSL for out-bound requests. If the external Web Service allows SSL, for example, the connection can be successfully established, even if SSLv3 is being used under the covers, from the custom Java code running in your Application Server.
One easy way to lock-down both in-bound and out-bound HTTPS secure channel negotiations to TLS is to simply enable FIPS 140-2 in the Websphere 7 Administrative Console.
By simply enabling FIPS 140-2 in Websphere 7, you can effectively limit all in-bound and out-bound HTTPS secure channel negotiations to TLS. Attempts by custom Java Client Code to use SSL will fail when run inside of the Application Server with FIPS 140-2 enabled. This will also help you ensure that you have the proper Ciphers enabled and limited as they should be (installing the proper Ciphers is another aspect in the proper configuration of an out-of-the-box Application Server installation).
When it comes to the Security of your JEE Application Server, paying attention to default configuration settings (and changing them as necessary), can yield significant dividends in protecting the data flowing through your systems. Common sense should prevail in grokking why this is important.