Vice President, Enterprise Security and Risk
Chris Gray is the vice president for Optiv's enterprise security and risk practice with over 15 years of experience in information technology, information security and information risk management. He leads the team in achieving customer requirements with implementing information security, risk management and compliance management programs.
Compliance May Be Compromising Your Company
GLBA, PCI, HIPAA, SOX … in today’s business world, almost every organization must address multiple types of regulations and standards. In many cases, such compliance is tied to specific dates with immediate fines assessed if the requirements are not met. As a result, so many people, regardless of industry, seem to spend all of their efforts and budgets on compliance.
There’s one major problem with this “throw money at the compliance requirements” approach. It does not necessarily make companies more secure. GLBA, for instance, requires that organizations protect their financial data, but it does not address most forms of privacy-related information or intellectual capital. PCI is driving companies to spend entire annual IT budgets on point solutions to address specific elements of the Data Security Standard. Unfortunately, with all of these requirements and costs, many of the organization’s other security program elements are pushed aside, leaving much of the company’s sensitive data (not related to cardholder information) with a much less secure posture. HIPAA protects medical privacy information around patient care. It does not, however, require many other important elements of a well functioning security program such as effective vulnerability management and risk-based decision making. Sarbanes-Oxley Section 404 assesses the effectiveness of internal controls around financial information, but beyond this scope, the security environment is largely ignored.
With all of these competing demands, companies are spending incredible amounts of money to achieve compliance, focusing on the checklist of required controls to avoid fines and reputational stigmas. Unfortunately, in addressing the specific goals of a specific regulatory requirement, the organization misses out on implementing a complete and well functioning security program. Rather than drive security strategy and architecture, compliance should instead be viewed as a result of an overall approach that ensures a proper data lifecycle - proper data classification, proper data collection, protection, storage and disposal. This distinction is critical since, in my experience, companies that do not adopt the viewpoint of proactively addressing proper data lifecycle rather than simply treating specific issues usually end up in a perpetually cycle of reactive fire-fighting.
Here’s a real world example to illustrate my point. One organization, a retail company with thousands of remote store locations, was aggressively addressing PCI requirements and spent a significant amount of money on point solutions to achieve compliance. Late in the effort of checking off all the PCI DSS compliance boxes, the organization, wisely, took a moment to begin an inventory of all valuable data that resided in their systems. One issue that arose was the presence of unencrypted data elements that could, together, be used to establish user identity – a definite risk for privacy violations by most state data protection and breach notification legislations. This information, however, was not a PCI issue, and it was shelved for remediation at a later date.
Unfortunately, before the changes could be implemented to address the issue, a physical breach occurred and the information was lost. An immediate assessment took place, involving external expertise to identify legal and regulatory requirements to address breach notification costs, required notification communications, and steps to address customer concerns such as credit reporting agency support to provide ongoing monitoring of credit-related issues to affected customers. Total cost? More than a quarter-million dollars to perform extensive privacy reviews, and nearly the same amount in external counsel fees and lost internal manpower hours. PCI fines are sometimes extensive, but agreements can often be reached with the acquiring bank(s). Shelving that real risk in favor of concentrating on compliance had a much more immediate, and likely expensive, price tag.
So, what is the lesson learned here? This situation should have been addressed by first pausing a moment to understand the totality of the problems before spending a cent on point-in-time, point-of-presence fixes. The second step should then have been to understand what solutions, from a conceptual point of view, needed to be implemented to mitigate the risks rather than just focusing on a checklist approach. Then, with risks identified and minimized through data lifecycle management, the scope of “real” work could have been reduced, and technology and process implementation could have been relied upon to truly secure the enterprise.
I guarantee that following a risk-based approach rather than a compliance-focused approach would have resulted in far less expense, greatly reduced the amount of time lost reacting to an emergency situation, delivered effective protection of carefully researched and identified sensitive data, and provided compliance with specific PCI requirements as well as other applicable regulation and standards.