If there’s one constant for security practitioners across virtually all organizations regardless of size, industry, or location, it is compliance. PCI, HIPAA, GLBA, EU Safeharbor, NERC/CIP, state laws, client contracts: whatever business you’re in, chances are there is at least one regulatory framework holding you accountable for some level of security. For many organizations, the primary goal of their security program has become simply meeting one or more of these standards. It can be very difficult for executives to make sound assessments of how likely a security breach could be for their organization, and determining its impact can be even harder. While a risk assessment can help to answer these exact questions, we find that most organizations don’t ask them in the first place until forced to by a “compelling event.” This can take the form of a security breach (at which point the checkbook will open wide for security initiatives), but more typically this takes the form of a third party pushing the organization to put basic security controls in place. Regulators are often better positioned to see the outcomes for organizations who aren’t taking these measures, and can enforce penalties for those who don’t fall in line. While these compliance efforts have certainly pushed many organizations to make dramatic improvements in security, which they otherwise would have been unwilling or unable to make, they are still a far cry from making most of these organizations as secure as they should be. It’s important to keep in mind that these regulators typically have a mandate based around the protection of specific information or infrastructure. Anything your organization does which falls outside of that is not a concern for regulators, and their compliance requirements may do nothing to help you secure those assets! A particularly acute example: one of SecureState’s clients had oriented their security efforts around achieving PCI compliance. While this was a clear requirement for doing business, credit transactions made up only a small part of their revenue. The bulk of their business had been built around valuable intellectual property for which they had no significant legal protections. Their CEO indicated that compromise of this data by a competitor could cause this company to go bankrupt in about six months. Being non-compliant with PCI would cost them thousands of dollars, but losing their intellectual property would cost billions. The problem for them was that there was virtually no overlap between the PCI systems and the ones holding valuable data. By focusing their security efforts on compliance, they had essentially left the front door open. Even worse, if a lack of vigilance around security results in a breach, regulators will rush to find proof that in some way you were not meeting compliance at the time of the breach. To date 100 percent of companies who we have conducted a PFI investigation for have been found to be non-compliant at the time of the breach, some of them despite having previously passed PCI audits. What we have often run into with PFI investigations is that the merchant completed the bare minimum actions that their payment processor told them to, or that were outlined in their Self-Assessment Questionnaire. Aside from issues that can arise from inexperienced personnel misinterpreting the SAQ requirements, this also makes compliance the equivalent of a standardized test instead of an essay question. The merchant can go through and fill in the bubbles, but they do not take away any more knowledge about security than they started with and rapidly fall out of compliance because they do not consistently review and update their security controls. In one case, we encountered a merchant that to most of the world was PCI compliant: they filled out their SAQ forms, got their metaphorical gold star sticker, and everyone was happy. Unfortunately, once they were breached we discovered that they really hadn’t been compliant in a long time: the scans they were doing were not all through a PCI Approved Scanning Vendor and other controls were not in place but had seemed that way to the staff members in charge. It was a small business, so the same people that were trying to run inventory were also given the tasks of being experts in security, networking, payment processing…you might be able to imagine the issue here. So if a merchant is only required to complete a brief questionnaire once a year to remain compliant, it is not surprising to people in the security industry that their compliance is likely lacking throughout most of the year. On top of the problems that arise from unregulated assets, even the assets that are subject to regulation still are not being kept safe once time passes and the threat landscape changes. Is this an issue that regulatory entities should address with different methods of checking compliance, like assigning random drug testing to athletes? Perhaps compliance with some of these protocols should include a mandate for continual education on information security. There are plenty of ideas on how to address the problems that we see regarding the gap between compliance and security, but each opens up its own can of worms and further challenges. And why would a regulatory entity care about a company’s other sensitive information? Right now the answer is that they don’t, but educating yourself on how to protect that other data could also lead to developing more insight or at least more awareness of why regulatory controls are in place, what they’re protecting against, and what they’re not. The result here would be that since you’re thinking critically about other types of data, you can apply what you know to securing regulatory data above and beyond the base requirements. This means fewer breaches, less money and data loss, and everyone being much happier. It can be challenging to meet the letter of every regulatory requirement every minute of every day. A great way to avoid getting into hot water with regulators is to build a security program that implements the appropriate controls beyond regulatory requirements, and works harder to detect and prevent security breaches of sensitive data. Good security means understanding what your own assets are, and taking the appropriate steps to protect them. Regulators have stepped in to tell you what those controls are for their sensitive data, but you have to make sure you’ve performed the same diligence for your own sensitive data. A little bit of foresight in assessing your own security risks and building an enterprise-wide security program to effectively manage them can help to avoid a billion-dollar mistake in the future.
