• info@helpingtesters.com
  • helpingtesters

Compliance is Good But Not Enough in Web Security

Compliance, Compliance testing in Web security, Compliance in web security, is compliance sufficient in web security

While testing a web application for security, we must try to expose as many vulnerabilities as possible. And compliance testing is one way of doing so. It should be admitted up front: compliance is a good thing. 

It truly is. Compliance, in a business sense, is the certification of meeting the requirements of a legal regulation or industry standard. In a data security context, compliance testing ensures a minimum standard of security models to ensure major industries, and even small businesses, operate within a margin of safety for their customers. At its heart, this is really is a good thing. But the question arises while testing the application in terms of security, how far should we go? Is compliance testing along enough to keep all malicious attacks at bay?

Compliance testing gives certain immunity to a business, but not to the fullest. In IT terms its considered as a D grade protection. Such regulations and standards designed with beneficial outcomes in mind, ensure a form of partial immunity, a.k.a. digital herd immunity to common malpractices that would otherwise endanger the security of their customers. However, herd immunity is not perfect, nor are any regulation or standard. Not everyone can or will participate, but at least the majority will be protected. Similarly, regulations and standards have to be generic enough to apply reason to the majority, which may exempt some or create problems for others. Adherence to such “minimum standard” could lead to catastrophic consequences.

Compliance testing is Also Difficult to Adhere To

When testifying before a U.S. Congress subcommittee in 2009 regarding the Payment Card Industry Data Security Standard (PCI DSS), Michael’s Stores Chief Information Officer Michael Jones stated:

[The PCI DSS is] very expensive to implement, confusing to comply with, and ultimately subjective, both in their interpretation and in their enforcement. … It is often stated that there are only twelve ‘Requirements’ for PCI compliance. In fact, there are over 220 sub-requirements; some of which can place an incredible burden on a retailer and many of which are subject to interpretation.

The PCI DSS has a reputation for being incredibly burdensome, especially for larger businesses, and worst of all for Level 1 Merchants (processing over 6 million credit card transactions per year). Because regulations and standards have to be generic to cover the majority, they often become incredibly complex and even have various forms of applicability from business to business depending on the auditor’s interpretation. The upcoming the European Union General Data Protection Regulation will require all ‘personal data’ of European Union ‘data subjects’ be ‘protected’. This is about as generic as a regulation can be.

However, consider this counter-argument from world-renowned cryptographer and computer security expert, Bruce Schneier, in an interview one year prior to Michael Jones’ testimony:

Regulation — … the credit-card industry’s PCI, the various disclosure laws … — has been the best stick the industry has found to beat companies over the head with. And it works. Regulation forces companies to take security more seriously

This is extremely true. When it comes to ensuring an application’s security, protecting the business and their customers is of utmost importance. The Equifax data breach of 2017 is just one example where warnings were given, and even regulations required such warnings to be heeded, and yet still one of the worst — if not the worst — data breaches in history still happened.

Where Compliance Falls Short

To better understand the shortcomings of compliance testing, let’s examine Equifax’s data breach again: They were required by law to protect their customer data, and yet they still had a massive security failure. Why? As earlier stated, compliance is all about bare minimums, and it indeed appears Equifax applied only the bare minimum security posture required by standards and law. They were required to patch their systems when informed of major vulnerabilities, and they did patch them — though, seemingly after being breached — so there could be a question of whether they were compliant within the regulatory bare minimums. Then who is to blame here — the weak regulations, or Equifax for not going beyond the minimums of those regulations?

Courts will quite likely rule that Equifax is at fault here, even if they did meet compliance because it is simply a company’s duty to protect their customers’ data even if how is not explicitly described in detail. The purpose of a standard or regulation is to set a minimum foundation that businesses must expand, enhance, and build upon in addition to those minimums, as applicable to their systems. For example, if a standard or regulation requires patching systems within so many months, do it as immediately as possible; if it requires a firewall — simply just a firewall — then configure it well, perform penetration tests regularly, and monitor it; et cetera. Take the minimums required, and extend them to the most reasonable maximums possible, even if the cost is high.

Compliance is inherently good, yes, but it also is only the starting point. We as testers should never let ourselves aim for the bare minimum but shoot for above and beyond the requirements. Not only because it is a good attitude in general, but also because it is best for our customers and business interests.

About the author

Vaibhav Singhal author

Vaibhav is in software testing since a decade. Worked with different testing techniques along with exploratory testing. Performed different regression, performance, api etc testing with tools and libraries like selenium, jmeter, loadrunner, protractor, rest assured, Katalon Appium and others.

Leave a Reply

Your email address will not be published.