Compliance or Security?

Tuesday, May 25, 2010

Mark Gardner


In recent days I have read a few comments like "that's compliance, not security." This has puzzled me. When did the two become divorced?

In the interests of full disclosure and for those who have not read anything I have written before, I am an Information Security Auditor, specialising in ISO27001, but I also Audit against other Standards and company policies.

I genuinely don't understand these comments, made when referring to a number of elements of information security. My first riposte is to pose a question. If you architect, design and build a superbly secure solution on a Tuesday, how is that security maintained on Wednesday when the services go live? Once live, I imagine that the architects and build team focus is on other projects, therefore the run and maintain of the security falls squarely into a Compliance function.

In assessing compliance it could be done against a standard such as ISO27001, COBIT, or it could be against a piece of legislation such as SOX, or it could just be against your Company Security Policy. Whatever means you are measuring against, the monitoring auditing and continuous improvement of security practices within your company the responsibility of  a compliance function.

In an isolated world, yes it may be the world's best all singing all dancing security suite, but once you put people in front of it, the solution is automatically made more vulnerable. As I stated in a meeting the other day on another matter "you can legislate for many things, but you cannot legislate the actions of users." Human interference is the biggest threat to any system. Therefore, security doesn't stop when you plug-in the last cable into the last firewall of your design. Monitoring of the rules on that firewall, assessment of the activity audit logs on that firewall, or of your Active Directory Domain, investigating an alert on the IDS, an update to the AV solution, all fundamentally are compliance functions, working towards maintaining security.

As an Auditor, you may find me or someone of my ilk a pain when asking for the numbers of audit logs recorded to be expanded, or for operating procedures to be created for the day-to-day activities such as building a database. These may assist investigating a breach of security, or the company recovering following a disaster.

Compliance may not be as glamorous as building and designing with the latest piece of kit from Cisco, but it, in my opinion, plays just as big a part in maintaining security.

Currently, the hot topic is Cloud computing, however, I put it to you, what is the big talking point about cloud? From what I have seen and read, across a variety of tech blogs, is that Security Compliance is key. If compliance isn't part of security, then why is it at the forefront of this huge development for computing?

Another example is the Microsoft updates, you may have built an excellent WSUS server to deploy the plethora of updates following patch Tuesday. However, patching is a form of compliance - a patch takes a system up to a certain acceptable security level.

I am not trying to be confrontational about this, I believe that the two areas work hand in hand to make sure the security placed on systems is acceptable. Security is a team Sport, it is only by working together will Security remain strong.


This blog was originally posted on my blog at

Possibly Related Articles:
Post Rating I Like this!
Peter Abatan Mark, I think I understand where both parties are coming from. I think seeing compliance and security as divorced is a bit far fetched. However I do believe that most security systems that are put in place are driven by compliance requirements rather than security requirements.

So asumming HIPAA, SOX, FSA, SEC etc are out of the picture, many organizations will not invest as much as they have now in securing their enterprise, and that is what many IT and Information Security professionals are saying.

I am sure that you would have seen on many occasions where the internal compliance requirements of an enterprise is way below required by external regulatory authorities.

For many organisations security forced by compliance requirements is a mandatory expenditure, while security based on its own internal compliance requirements is a discretionary spend.
Jeremy Licata, CISSP, CISA I don't see compliance and security as divorced. But they do seem to be related more as stepchildren...

A clear distinction must be made between security and compliance. I have no problem telling a client that they are compliant with their security program; I cannot tell them that they are "secure."

Compliance focuses on evaluating the implemented security measures against a set of specific requirements. All of the documents, artifacts, logs, and related paperwork are intended to provide evidence to the auditor that the environment conforms to defined requirements.

Security, it can be argued, is driven by threats, vulnerabilities and, ultimately, by risk. Risk is expected to drive the development of requirements that are ultimately used for compliance. But security does not stop there. With an ever-changing security landscape, the requirements, and compliance with those requirements, rarely ever can keep pace with changing risks.

One caveat that I always provide my clients is that the evaluation is for a "point-in-time." The evidence that is provided only covers compliance during the time that the evaluation team is performing the evaluation. We make no claim to system compliance after we complete our assessment.

My teams also do not comment on the "security posture" of the system because we are not evaluating security -- we are only evaluating compliance with the security requirements.
Mark Gardner Wow, thanks guys for your comments. I knew it would be slightly controversial but I didn't expect so many comments so quickly, it hasn't happened on my previous blogs!

I think ultimately, what I have tried to say is that a security audit works in conjunction with what is architected. I as an auditor, take what is architected and using 27001 as a framework assess, in a pragmatic fashion what has been put in place. It may be that I spot things that fit into the standard, i.e. Audit logs and make a recommendation around that.

For me a ticklist audit ending with a stamp saying compliant is almost a waste of time. An evidence based audit with a real security focus is more what I was referring to and I do honestly think it helps to improve the security of the services provided.

Jeremy, I agree with your comments wholeheartedly. I would never tell someone they are secure - I get especially nervous around products which state they are 100% secure - don't believe them and that is something that can never be said. At the end of the day the recommendations made in respect of the security compliance, are down to the business to accept and implement - to not do so means their security is non compliant and potentially at risk. Not an issue for the Auditor - that's for the business and asset owners to decide.

Lance, I agree - just having a Pen test is a waste of money - but a quality pen test with full reporting and recommendations, if implemented, has got to be worth something?
Anthony M. Freed Great Post Mark! I'd like to make the point that compliance is supposed to enable better security, but it's little guarantee.

Note the time line of the Heartland breach:

December 2007 - Company had knowledge of a breach in their corporate network, but not in payment processing systems.

January 2008 - Processing likely first breached, lasted discovered in fall 2008.

March 2008: Heartland passes PCI compliance audit.

So, the audit and subsequent compliance stamp of approval occurred during the breach.

The topper is the PCI standards council immediately released a statement the "no PCI compliant company has ever been breached", and they removed from the compliant list.

This line of thinking could lead one to believe that no PCI compliant company is really PCI compliant, they just have not been revealed publicly to have suffered a data loss event.

Really, what good was that compliance status for Heartland if it did not prevented the breach, did not detect the breach during the QSA, and did not give them any cover when the breach was revealed?
Mark Gardner Anthony, thanks for the positive feedback and the challenge!

My point is given that it was the payment processing system why were not sufficient controls in place to monitor activity? That t me is a joint issue - architecture in place to record, someone in place to monitor - especially a key system such as that?

Obviously I have issues with the QSA too, but wihtout a full knowledge of the case cannot say too much other than, yes the process is open to huge questioning.

Taking Jeremy's point from earlier - surely this was a risk assessment issue? If they'd risk assessed the systems and implemented mitigations - again a joint responsibility then the breach could possibly have been prevented?

In my post I'm not saying that compliance is the panacea, what I'm trying to say (possibly badly) that compliance should be part of an holistic portfolio rather than seen as a separate entity or even in some cases the enemy.
Anthony M. Freed Mark,

I totally agree with your sentiments in the last comment, I just like to bring up Heartland because it is a perfect storm is so many ways.

As background - In January of 2009, I began writing a series of articles questioning the timing of Heartland Payment Systems CEO’s 2009 stock sales that occurred during the same period the breach was reported to have occurred.

One Month later, the SEC announced an investigation into those sales, and my articles were later cited as Scienter Evidence in an investor initiated class action lawsuit (See Items 117-119 from HEARTLAND PAYMENT SYSTEMS, INC. SECURITIES LITIGATION ).

The suit was dismissed, but it signals an emerging trend where infosec management intersects investor disclosure.

The comments on risk assessment are central to issues related to shareholder value too - Heartland lost half of it's stock value NOT after the breach happened, but after the breach was reported publicly.

Network vulnerabilities need to somehow be accounted for in regards to investment risk in publicly traded companies too.
Ray Tan Human interference is the biggest threat to any system.
This is absolutely true.
Mark Gardner Cloud Ninja, Firstly thank you for sharing these documents I found them fascinating.

My intial thoughts are that they echo many of my own thoughts and certainly the two Global Foundation Services documents felt very familiar and made a great deal of sense to me.

In what was my first post for this site ( I made many of the points raised in these documents.

I need a bit more time to digest the other two documents but would love to talk with you more on these subjects.

mk MK
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.