Compliance risk, the risk management trump card

Organizations that perform risk management are generally aware of the laws, regulations, and standards they are required to follow. For instance, U.S. based banks, brokerages, and insurance companies are required to comply with GLBA (the Gramm Leach Bliley Act), and organizations that store, process, or transmit credit card numbers are required to comply with PCI-DSS (Payment Card Industry Data Security Standard).

GLBA, PCI-DSS, and other regulations often state in specific terms what controls are required in an organization’s IT systems. This brings to light the matter of compliance risk. Sometimes, the risk associated with a specific control (or lack of a control) may be rated as a low risk, either because the probability of a risk event is low, or because the impact of the event is low. However, if a given law, regulation, or standard requires that the control be enacted anyway, then the organization must consider the compliance risk. The risk of non-compliance may result in fines or other sanctions against the organization, which may (or may not) have consequences greater than the actual risk.

The end result of this is that organizations often implement specific security controls because they are required by laws, regulations, or standards – not because their risk analysis would otherwise compel them to.

Excerpt from CISA All-In-One Study Guide, second edition

Going public with website vulnerabilities that expose credit card numbers

I am a customer of an international company whose logo is highly recognizable and whose brick-and-mortar services I use frequently. I pay for these services by credit/debit card on their website. I noticed two months ago that the website has a vulnerability that exposes credit card numbers through form field caching, which means that public-access computers could expose credit card numbers (and security codes) to others.

I have contacted the company three times in the past six weeks. Their website makes it impossible to know who their security people are or which continent they work on (this is a company that has presence in over 100 countries). I have written the press office three times. None of my communications have read by a human, as far as I can tell.

I will be giving them another week or two before I go public. I’ve told them so in every way that they make available. After telling them almost two months ago, I logged on today and the vulnerability is still there. It is SO easy to fix – it does not require any changes to their data model, workflow, or processes. All they have to do is add an ‘AUTOCOMPLETE = “off” ‘ to two fields in one form and they’re done.

As a security professional I am duty-bound to inform this organization. I’ve done so many times, and have not heard any response. If they continue to turn a deaf ear, I will go public in April.

Multiple, overlapping audits

Are any of you on this group in organizations that are subject to multiple sets of internal or external audits that overlap? If so, how do you handle the duplication of work?

In my organization, we have external PCI audits, external ISO27001 audits, external SAS70 audits, external Sarbanes Oxley audits, plus we are required to do internal audits for ISO 27001 and Sarbanes Oxley – most of which concentrate on the same things: general computing controls, the protection of sensitive data, and the integrity of our applications.

What is particularly frustrating to control owners/operators is having to answer the same questions and produce the same evidence time after time for these different audits. One thing that is helping is automation of many of these audited tasks (or automating the recordkeeping), which makes evidence collection easier.

Are any of you experiencing this? Please share.