A new whitepaper from Reymann Group promises “compliance for free.”  Too good to be true?  Not really.  What’s the catch?  There is none.

My executive summary of the paper is this:  If you have a compliance program, you almost certainly also need a security program.  But if you have a security program, you may not need a compliance program.  (With apologies to the authors for oversimplifying their message.  Go read the paper and see for yourself.)

Why is this?  Several reasons:

• A compliance program targets a minimum baseline that may represent a compromise to accommodate a broad population of affected implementations.
• A compliance program is based on a standard that always lags significantly behind the threats due to the time required to codify and ratify any changes.
• A compliance program aims at a fixed target where update cycles are typically measured in years.

Because of these factors, a compliance program may be useful in obtaining favorable audit results but probably does not address the comprehensive security needs of the enterprise.  So somebody must be tending to enterprise security, despite the existence of compliance program.

On the other hand, a decent enterprise security program is going to address all the compliance issues and more:

• A security program does not stop at the minimum baseline but seeks to implement security appropriate to the business context and risk.
• A security program is dynamic and evolves rapidly to meet new threats.
• A security program is not measured in assessment cycles or versions but may change as rapidly as required.

A good example of this is my favorite middleware product, WebSphere MQ.  Until recently, WebSphere MQ was not the subject of too many compliance audits.  In the absence of an audit requirement, a compliance program would have had no reason to look at the middleware layer.   A security program on the other hand would have recognized the business value, and therefore the intrinsic risk, of the messages in the middleware layer.  With a focus on security rather than on compliance, such a program would have recognized basic security needs such as authentication, authorization, data integrity and data privacy and addressed these in the midleware network.

The difference in these two approaches will soon become apparent.  The 2008 update of PCI-DSS and the growing frequency of network breaches has shone a spotlight on network security and WebSphere MQ is increasingly recognized as a critical component within the scope of any compliance audit.  In many cases, a company’s next audit will be the first ever to formally include WebSphere MQ.  Shops that have relied solely on compliance programs will probably be ill-prepared for a close inspection of their middleware network and may fail their audit, despite having previously passed.  But shops with a robust security program will likely have already configured their messaging network as though it were already in scope for the audit.  These shops may pass the audit or require only minimal remediation.  I use MQ as an example here but the principle applies to any technology.  As Reynmann Group points out, focus on security first and you get compliance for free.

If you are wondering what an audit of WebSphere MQ might entail, come visit me at T-Rob.net or read my Mission:Messaging article WebSphere MQ, PCI DSS, and security standards.  For more information on WebSphere MQ security, download my podcast The Deep Queue.

Tags: audit results, Authentication, authorization, compliance program, data integrity, data privacy, middleware compliance, PCI-DSS, security compliance, WebSphere MQ