Warning: Regulations May Harm Your Security

Like many of you, I have spent decades trying to devise security controls that comply with various regulatory requirements. In some cases, they are actual regulations, like FINRA 17a-4, GDPR, HIPAA, NYDFS Part 500, and PCI DSS. In other cases, the regulation is an industry standard to demonstrate adequate controls to business partners and customers, such as NIST CSF and SOC 2 Type II; or a requirement for some customers, such as FedRAMP.

While every one of these is well intended and they all have some requirements that are sensible, they also have the potential to cause harm, primarily in one of two ways. 

Regulatory Compliant Does Not Mean Secure

Regulatory compliance is often presented as a voucher or certification. Management often celebrates that we “passed our certification”. First, most of the regulations are not actually certifications. For instance, as a merchant, you are not “certified” under the Payment Card Industry (PCI) Data Security Standard (DSS). You are assessed, and you were deemed to, at that point in time, implement a compliant set of controls. It does not mean your security is great, or that all your systems are secure, or that you cannot leak data, or that you will be compliant at any point in the future. Assessed and compliant organizations are compromised all the time, and data does leak from them. The assessment might have been incomplete, the security state changed, or a component that was not assessed failed. 

No assessor or auditor can assess the totality of an environment. Some barely try. They believe what the company is presenting, and the company wants to present itself in the best light possible, yet every organization has weaknesses. Failing the assessment does not look good for the team.  Executives also often misunderstand regulatory compliance and audits, and fail to use them to their advantage. This is one of the great problems in Information Security. If you present a story that passes the assessment, you are thanked by upper management, who concludes that you obviously have all the resources you need, so you don’t get any more. If you fail your assessment, you are blamed, deemed to be squandering company resources, and at best, won’t get any more. Every security team is understaffed. That’s a fact even in organizations regulated under requirements such as New York Department of Financial Services (NYDFS) Part 500.4, which requires sufficient resources to staff the cybersecurity program. I’ve yet to see any organization state to a regulator that no, we do not have the staff we need to fully manage the cybersecurity program.

This is the second part of this problem. The auditors. Regulations, by necessity, are shallow and broad, and the time allocated for the audit is limited. This means the audit often is shallow. Anyone who has done (proper) acquisition due diligence knows that the answer is not in the question but in how it is answered. Follow-up questions usually get to far more truth than the original question. However, I’ve seen many regulators ask questions like “Do you have a data classification policy?”, to which the company of course answers “yes”.

Had they asked the follow up question of “please show me the data classification policy and an example of how someone in position X would use it” they might have learned that it defines data as either “public” or “non-public”, lives in a Word doc that only four people have access to, and that nobody other than the people at the other side of the current table/zoom call have ever seen it. 

They then move on to ask “do you label your data according to the policy?” and are satisfied with “yes.” Just one follow-up question would have discovered that the labeling is an Excel sheet that contains a print-out of a partial schema of the data warehouse, not a production database, with labels that do not match the data classification policy. 

These types of audits are at best not meaningful. At worst, they lead to ultimate outcomes that are harmful. Harmful to customers. Harmful to the business. And, harmful to shareholders. This is a problem that must be solved by the regulators, not by the regulatory targets. The problem is largely not the contents of the regulations but the depth and implementation of the audit. Furthermore, the consequences of non-compliance create enough of a disincentive for the target that they avoid it at all costs; to the point of misrepresentation in some cases. This causes them to lose an opportunity to improve. If regulators were better staffed, better trained, and partnered with the regulatory targets rather than the current relatively adversarial relationship, they could achieve outcomes with far more long-term success. Instead, we are caught in a vicious cycle where regulation is something to get over and around, not something that actually has meaningful outcomes.

Focus On Compliance Redirects Resources From Real Concerns

The second way regulations can be harmful is, perhaps, more insidious. Regulations tend to require controls that do not improve security, or that actually are harmful. Even those that do no direct harm are actually a problem because they still have to be complied with, even though they waste resources on things that do not matter. 

PCI DSS is one of the oldest regulations and, in the defense of the PCI council, it actually is one of the more reasonable ones. However, even PCI DSS 4.01 requires rogue wireless network detection within the Cardholder Data Environment (CDE). The problem is not whether there are other wireless networks accessible within the CDE but whether any of the hosts in that environment connect to it and sends cleartext data to it. Rather than have someone waste their time walking around with an antenna scanning the airwaves every three months, the covered entity should ensure that hosts only connect to legitimate endpoints and that all traffic is encrypted.  

An example of regulations that could be harmful is the requirement to implement anti-malware and intrusion prevention on every host. This requires running costly, unnecessary, and ineffective software on hosts that have extremely limited exposure to malware in the first place. Rather than anti-malware software, which has been of dubious effectiveness for many years, server infrastructure should be configured to only run allow-listed workloads. Any unwanted software that can evade these types of controls would surely evade anti-malware software too. Intrusion prevention is best done at the network and logging layer using aggressive logging, real-time analysis, and automatic quarantine and rebuilding of hosts, rather than agents on hosts that add vulnerability footprint. In my days as a penetration tester, I actually compromised hosts, including an entire very large network, by leveraging security vulnerabilities in the intrusion prevention software. Other requirements, such as data loss prevention software may not be directly harmful, but the vast majority of organizations are not at the level where it could be useful, so their efforts are best spent somewhere else. 

While PCI DSS has evolved, it still contains outdated password guidance. 

“8.3.9 If passwords/passphrases are used as the only authentication factor for user access… Passwords/passphrases are changed at least once every 90 days” 

and 

“…locking out the user ID after not more than 10 attempts.” 

This was bad advice 20 years ago and it is damaging today. First, account lockout is a great way for an attacker to disable a system, and it is ineffective at what it purports to do - preventing password guessing. Any attacker who engages in password stuffing today knows better than to try 11 passwords on the same account if lockout is enabled. Rather, they will try the same password on 11 accounts, and only cycle back to the first account once the lock-out counter has reset. There is also no password that is magically bad after 90 days but good until then. Passwords are either good until they are phished, or bad immediately - with most falling into the latter category. 

Yet, organizations are forced to implement user-hostile password policies to comply with these types of regulations. This hampers productivity, annoys users, and fails to solve any security problem. The solution is really rather simple - make passwords useless on their own. The regulations should be changed to: 

“If passwords/passphrases are used as the only authentication factor for user access the assessment cannot be completed until the organization has implemented strong multi-factor authentication (MFA).”

f you already require good MFA, you should argue for the magic words: “compensating control” to avoid the user-hostile requirements in the current regulations. 

Not all multi-factor authentication is the same. I’ve written extensively about this before and won’t repeat myself here, but I’ll give you the short version: use FIDO 2 based MFA. Only. Hardware tokens such as Yubikeys are great. Passkeys are very good, have high potential for user acceptance and ease of use, and are relatively easy to implement. Proprietary technologies are typically an unknown quantity and may be good, but may not. Virtually every other form of MFA, including SMS delivered tokens and time or hash based token codes are phishable. Push-based approval notifications (“Yes, that was me / No, it wasn’t me” buttons) are roughly as secure as no MFA at all.

This is one area that NYDFS Part 500 gets right. It requires MFA, although it fails to specify FIDO 2 based MFA. To be compliant, your vendors must support MFA, and you, as the customer of those vendors, must insist that this is a standard feature. Some vendors do not support FIDO 2 MFA (Workday on iOS e.g.).  Other vendors, such as ADP, charge extra for MFA. This is unacceptable. MFA is table stakes today and must be included in and/or supported by every product.

Conclusion

This article is getting long, and I will end here. After all, picking on regulatory requirements is a bit like the proverbial shooting fish in a barrel. Doubtless the regulators mean well, and many of the regulated entities do as well. However, the current state is problematic. Not all of these problems are easy to solve, but one of the simplest things you, as a senior leader in a regulated organization can do, is to ask that additional question: did we pass the assessment because we are doing the right things, or because we spun a good story? What are our biggest weaknesses? What do you, the CISO, need from me?

Ad: Could you use a deep, factual security assessment? A strategic security plan? A review and update of your policies, implementation, and plan. Do you need to discover the highest impact controls you should implement based on your current state? Are you a C-Suite executive interested in an independent evaluation of your security team or are you considering an acquisition and need to understand its security state? Or do you need individual strategies for internal use of Generative AI, Least Privilege, or Zero Trust? I’m an independent consultant with over 20 years of technical security leadership, c-level advising, strategy development, and training experience. Please reach out if you would like to discuss these services.