Proper Web Application Security Is About More Than Just Compliance

ads space

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.

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.

ads space