Category Archives: Computer Security

'Out of the Box' Rubik

‘Out of the Box’: Your COTS Products Are Not Secure

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.

Websphere 7 SSL and TLS
Websphere 7 SSL and TLS allowed by default.

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.

Enable FIPS 140-2 in Websphere 7
Enable FIPS 140-2 in Websphere 7.  The default setting is ‘Disable FIPS’.

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.




Email Encryption Made Easy(er)

Dear Internet User,

You need to encrypt your sh*&^! There is no excuse to have your personal information, ideas, or other personal communications intercepted and read by prying eyes – such as Google, the NSA or anyone else for that matter. I have had my personal data stolen on at least two occasions so far, because third-party contractors, health care providers, etc do not take information security seriously; moreover, they are all pretty much clueless – and the U.S. Government does not care a lick if your personal information is not secure. But that does not mean you have to be apathetic and clueless too! Start by encrypting your email. It is fairly straight-forward, but it requires at least one friend or family member to be on board with encrypting email.

In general, here are some steps you can follow to get set up to encrypt your email communications so that it becomes too expensive for the US Government, Google, Yahoo or other organizations with a vested interest in seeing what you send over the internet, from being able to do so:

  1. Download and install GNU Privacy Guard. There are Windows, Mac OSX, and Linux installations so it’s easy no matter the platform.
  2. Download and install Thunderbird, the email reader from the Mozilla Foundation.
  3. Install the Enigmail Thunderbird Plugin, which will make it easy to encrypt and decrypt email messages.
  4. The Enigmail plugin will walk you through generating your Public and Private PGP Keys. You will need to export and share your Public PGP Key with friends and family you wish to send encrypted email to.

Once you get all set up, feel free to test your setup with me. You can send me your Public PGP Key and we can test sending and decrypting email messages so you can get the hang of it. Our freedom depends on our ablilities to hide personal information from unintended audiences.

My Public PGP Key: click this link and import my Public PGP Key into your Keyring.