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.
No comments:
Post a Comment