Proper Web Application Security Is About More Than Just Compliance

A Compliant Web Application is Not Necessarily Secure.

Compliance regulations are guidelines to help businesses build and maintain more secure web applications, though in reality it takes more than being compliant.

• The Problem with Simple Compliance.
• What Happens When You Fail to Eliminate all Web Vulnerabilities.
• Moving Beyond Compliance.

Our natural inclination when it comes to building and maintaining a secure web application is to refer to the appropriate compliance standards. Service providers and companies are often under the notion that if they are compliant, they are also secure.

After all, it would make sense that the governing bodies, for example, the PCI Security Standards Council and even governments responsible for establishing specific security standards, would understand the process involved in developing and maintaining a secure web application.

Unfortunately, this couldn’t be further from the truth. Most industry standards and regulatory bodies do little more than outline minimum acceptable requirements. As a result, they leave companies, service provider and developers with a false sense of security — a feeling that they have done what’s required to avoid a security breach.

Let’s take a look at two specific examples where the concept of compliance falls short. First, we’ll look PCI-DSS and PA-DSS (PA applies to third-party payment application software). Clearly, these represent two of the more thorough compliance standards — actually outlining some of the specific requirements such as identifying each system component that deals with cardholder data and implementing a methodology for penetration testing. These details are outlined in 11.3 and 11.3.4 of version 3.0 of PCI DSS . Although PCI DSS mentions the importance of vulnerability remediation, some of the more specific details are left for you to implement as a developer or end-user.

Unfortunately, other compliance requirements are often vaguer — especially some of the regulatory acts put in place by individual governments. Obviously, you want to be compliant with local and international standards but it’s simply not enough. For example in Canada, the PIPEDA (Personal Information Protection and Electronic Documents Act) outlines the requirements for the collection, use and disclosure of personal information. Considering the importance of securing personal information, you might be surprised to find that the only mention of “Safeguards” occurs in section 4.7.3 where it says “The methods of protection should include: c) technological measures, for example, the use of passwords and encryption”. Not only is this vague, but even someone with the most basic knowledge of web application security would realize how inadequate this requirement is.

If ever there was a reason why compliance itself might be inadequate, both of the above examples should make it clear. Especially when you consider the potential ramifications of a security breach.

Exposing, identification and remediation of all web vulnerabilities are a continual game of cat and mouse. The idea of a 100% secure application, while impractical, should still be your overarching goal.

While it remains important to perform a cost-benefit analysis, it’s also important to understand that it’s not always possible to predict the ramifications or true cost of a poorly constructed security posture until it’s too late. Government regulators are one concern — the often vague compliance requirements make the potential for penalties a high-risk proposition because we all know that ignorance is not an adequate defense. In 2015 AT&T was hit with a $25 million penalty related to the unauthorized access of customer data.

Compounded on top of the regulatory penalties is the potential for a security breach to damage customer goodwill and destroy client relationships. Yes, this is a difficult metric to measure, but again, it is really worth the risk?

Some risks are easier to quantify. For example, if a hacker was able to access your database by exploiting a SQL Injection vulnerability, potentially crippling your web application or eCommerce store, what would it cost your business in terms of lost revenue for each day? How much will it cost to identify the point of entry and implement appropriate remediation after the fact? In most situations, it costs less to be proactive.

Obviously, compliance is important — it should be considered a critical first step in demonstrating that you have established an effective security posture. In the case of PCI DSS, even if you’re a small service provider, it’s a good idea to perform regular self-validation and to keep written reports that demonstrate your commitment to compliance.

In the event that your organization is not classified as a small provider (or merchant), you’re probably already aware that your compliance and reporting requirements are much greater. PCI DSS even goes as far as providing Pen Testing Guidance. You need to be able to demonstrate compliance — especially in the event of a breach.

As soon as you are prepared to move beyond simple compliance (especially where PCI-DSS isn’t involved), it’s important to come up with a plan that includes several components:

1.    A thorough and documented understanding of potential risks and points of exposure. What data and which systems are most critical to your business? Have you covered all potential attack vectors?

2.    A clearly defined set of goals and objectives that are prioritized, if need be, depending on budget constraints. You may not be able to eliminate all vulnerabilities at once but you should have a plan to do so (beginning with the most critical).

3.    A strategy that outlines how you’ll implement your plan. This can include the use of third-party consultants, penetration-testers, automated vulnerability scanners which can be integrated into you SLDC and an outline of individual team member responsibilities.

4.    Finally, it’s important to implement a method of reporting and recording results. If you can demonstrate how your security posture has improved over a period of time or which vulnerabilities have been eliminated it becomes easier demonstrate the effectiveness of your vulnerability management program. In the event of a security breach, being able to demonstrate good stewardship can prove invaluable.

The objective of this article was to not to discount the importance of maintaining compliance — it’s always something you’ll have to deal with in one way or another. What we did want to accomplish was to demonstrate both why compliance alone isn’t enough as well as some of the simple steps you can take to improve your overall security posture. Industry and regulatory compliance should always be looked at as a point of departure, not the final destination.