Following the White Rabbit Blog : compliance

Compliance: Ushering in the Apocalypse!?

RafalLos — Mon, 17 Nov 2008 03:56:00 GMT

I read an interesting article tonight, on my flight out to Washington, DC for the CSI Conference (where I hope to meet some of you... ping me if you're here and I haven't talked to you yet). This article, titled "The Coming HIPAAcalypse", presented a very grim view of compliance with the HIPAA regulations, but the author could have just as easily been talking about PCI or any other regulation. As I read this article I couldn't help but think... "What does it have to be this difficult?" I say this from experience, having been there in the thicket of PCI compliance in a previous job - trying to manage the complexities of budget, compliance need, and resources with frustration to spare - but does it really have to be so hard?

Thinking in the context of web applications - that's the focus of this blog - everyone has them in their business. What's more, everyone has mission-critical applications in their business. Further than that... these applications must be available, usable AND secure... 24x7x365. This can at times seem like an unattainable goal when you add compliance to the mix. You know you've been there, and you've wondered how you're going to solve these issues.

I offer a glimmer of hope. When it comes to compliance, automation is the key. You won't get more staff, more budget, or more resources especially with the looming economic conditions so how do you get into the compliance winner's circle? Automation. If you can find a way to automate some of your security "testing", you may be able to get complianct faster and have a few dollars left over for other critical security initiatives. Automation of testing, data aggregation, and presentation of IT Risk as a component of compliance makes it easier to not only assess where your company is on the compliance journey - but also helps to (to use an old cliche) "do more with less". If you're facing compliance challenges, and web applications are involved... this should ring bells for you. If you're interested in hearing more, or a message more customized to your specific situation - contact me directly, I may have an answer you can live with.

PCI Compliance Madness - See! I'm not insane!

RafalLos — Sat, 25 Oct 2008 05:41:00 GMT

Rich Mogull over at Securosis totally nailed it. This article he put up talking about the Web Application Firewall (although it's still a mis-named product, see my rant here) vs. secure coding is brilliant. I've been saying this since I can remember hearing about "WAFs"... and it's nice to see someone out there that people actually recognize (Rich is an industry heavyweight) echo this sentiment... although the analogy of using Cajuns and gumbo is probably beyond my abilities :)

Still thinking about this as I sat here and re-read the PCI DSS current standard (and supporting documentation)

{PCI DSS}
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

Installing a web-application firewall in front of public-facing web applications

{/PCI DSS}

A few things immediately hit me that I felt the immediate need to comment on, because my mind now thinks in terms of "if I'm a business leader, how do I find loopholes in this...". Here are my thoughts:

I am having an issue with the term public-facing being there. I'd be OK with business-critical or something that indicates the application/site hosts critical data (such as user information, credit card numbers, etc). What if I'm a business and I have 100 "public-facing" sites, but they just all happen to be brochure-ware. Granted I am a card processor. Does it make sense to put non-mission-critical (or containing no critical data) sites through this review process?
"... after any changes" - so if I change the background, or add new legal verbiage I have to re-submit my site to inspection? That makes no sense from a business perspective... does it?
Notice that it says "Review" and not "Review and mitigate any critical issues found within x time-frame"; does this bother anyone else?
The word "either" implies an OR clause here... why does the PCI DSS council see Security Review and added protection as an OR?

As you can guess, I can come up with no less than 5 scenarios where I'm [assuming I'm a business which should be compliant with this policy] going to be horribly security-deficient while still being PCI Compliant. So once again, I'm going to return back to this question and I want everyone to think about this carefully. Would you rather be PCI Compliant, or secure? Further, does compliance equal security?

Security and Compliance - Strange Bedfellows Indeed

Rafal Los — Thu, 01 May 2008 14:24:00 GMT

It's a classic problem of which came first... the chicken or the egg? politics or corruption? security or compliance? While I admit, it's not such a strange thing to see the two groups working together these days... I would like to point of some of the issues that I've come across between these two very important groups in today's enterprises.

The issue of compliance is much like the issue of legal counsel. All large enterprises, and even most small business have someone that's responsible for compliance - occasionally you'll see an entire department dedicated to the daunting task of keeping up with regulations, compliance policies, and the ever-changing landscape of procedural accountability. Oddly enough, there is not a one-to-one relationship between the compliance department and a security department. I've spent a large portion of my IT career in situations just like this and I would like to share some of my understanding with you.

Compliance, while not always a necessity in private businesses, is almost always present in larger, pubilc enterprises. The compliance department is responsible for making sure the business is in-line with self-imposed corporate regulations and policies, industry-consortium regulatory guidance, government oversight and policy even international laws too! It's amazing these groups can even keep this stuff straight, right? What's equally amazing is how often compliance relies on IT Security for guidance and implementation of compliance components. This of course begs the question - would IT Security exist in some organizations if there was no compliance stipulation for such groups? On the flipside of that... in a perfectly secure world where no one is ever malicious - what would be the need for the compliance group? So while it may be a stretch to say that one group cannot function properly without the other (I will concede that they can, albeit poorly) each is heavily dependant on the other for its very existence within a business. This is where I find some strange... interactions.

As I've stated, the security team often carries out part of compliance policy or regulations; or performs audits to ensure that the same regulations are being followed - but I feel like even in these cases the synergies between these groups are under-utilized. I can't count the number of times I've been turned down for an IT Security initiative (which made perfect business sense, by the way - but was simply under-funded) only to push that same initiative through under the guise of a compliance regulation - through the compliance team. In return... the compliance teams I've had the pleasure to work with have repeatedly called upon my security resources to be the "muscle" behind their policies.

As I travel and talk to different groups about Application Security, I am agaff at the number of times that I get an entirely blank stare when I try to explain how leveraging compliance is a sure-fire way to get security initiatives done. Here's my reasoning... see if you disagree...

Compliance is a "necessary evil" which exists to keep the business in good legal and regulatory standing
IT Security exists to keep the balance of risk/reward within the business IT as balanced as possible
IT Security should be looking to enact initiatives which work to support the business

If you take all 3 points above as truth (and I firmly believe they are) then it's a logical next-step to say that IT Security initiatives and Compliance initiatives will greatly overlap. An overlap within two very necessary units of the enterprise will always, without fail, lend more credibility to their efforts and causes. If both the security and compliance teams are pushing the same agenda, it becomes very difficult for a business owner to simply dismiss that agenda as unnecessary or frivolous.

So a lesson-learned here - if you're not already doing this... here are some very simple yet extremely effective (based on personal experience and first-hand accounts) techniques for getting things "done".

Open a regular dialogue with your complaince team. Meet once a quarter, once a month, or once a week as permissable to discuss what you're independently working on
Find overlaps in your goals from a non-technical perspective
Create a joint strategy for compliance and technical implementation of initiatives previously agreed upon
Review business requirements jointly - ensure that both groups understand each other's point-of-view

Given these very simple, and probably obvious, steps - I can virtually guarantee a more successful IT Security goal achievement. You'll work less uphill, you'll "win" more often, and you'll do a much better job not only understanding but supporting your business - that makes everyone happy.