Information security, as most readers must surely be aware by now, is
primarily concerned with the preservation of confidentiality,
integrity, and availability of an organization’s information systems
and resources. Countless regulations now dog the electronic payments
industry that mandate business to enact certain protections and process
to ensure the safety of customer information. Between the newly minted
privacy regulations that are being passed around the country and the
established legal mandates and industry standards, the payments
industry has undergone an almost seismic shift in its information
security posture. Most companies have dutifully undertaken
penetration tests, risk analyses, and network re-architectures in an
attempt to comply with the ever growing list of requirements. While
these are important steps, they fail to address the most common way in
which security breaches occur: through the application.
The oft-quoted Payment Card Industry (PCI) Data Security Standards
contain several requirements regarding the placement of servers and
firewalls. It requires placing intrusion detection solutions on the
network and establishing complex, segmented network architectures
employing Demilitarized Zones (DMZ) to protect databases holding
cardholder data. It also contains frequently overlooked requirements
pertaining to the security of the applications running on the networks.
Requirement 6 of the PCI requires companies to “Develop and maintain
secure systems and applications.” Specifically, Requirement 6.3 states
that:
6.3 Develop software applications based on industry best practices and
include information security throughout the software development life
cycle. Include the following:
- 6.3.1 Testing of all security patches and system and software
configuration changes before deployment.
- 6.3.2 Separate development/test and production environments.
- 6.3.3 Separation of duties between development/test and production
environments.
- 6.3.4 Production data (real credit card numbers) are not used for
testing or development.
- 6.3.5 Removal of test data and accounts before production systems
become active.
- 6.3.6 Removal of custom application accounts, usernames and passwords
before applications
become active or are released to customers.
- 6.3.7 Review of custom code prior to release to production or
customers, to identify any potential coding vulnerability.
Typically, when using Off-the-Shelf (OTS) technology, companies depend
upon the vendors to provide secure applications and to maintain and
update security patches, as appropriate, for the programs in question.
The importance of maintaining up-to-date security patches is discussed
in Requirement 6.1 and 6.1.1 of the PCI. A process must be established
to locate and install the latest security patches, using proper change
control procedures. There are a number of services or products that
can help companies with this function. Unfortunately, many OTS
applications are not developed with security in mind. A quick Google
search will yield hundreds of results listing known vulnerabilities in
a number of different common e-Commerce applications.
It is also unfortunate that when developing custom applications, many
companies neglect to ensure that their code is secure. This can be
overlooked for a number of reasons: simple negligence, feeling guilty
about “second-guessing” the development team, or simply being
overconfident about team’s ability to develop secure applications. The
fact remains however, that applications are the most common point of
failure in the information security program. The vast majority of
security breaches in the industry are caused by compromises of the
web-facing applications. In fact Gartner, Inc. has noted that almost
75% of attacks are tunneling through web applications. While a number
of different methods are used to compromise an insecure application,
two common methods of attack for eCommerce applications are SQL
injection and Cross Site Scripting.
In most web forms, information entered in an input field is entered
into a Select query, which will return the appropriate information from
the database. Frequently, no provisions, known as input validations,
are taken to prevent users from entering information other than their
usernames or passwords. A SQL Injection attack takes advantage of this
oversight. In a SQL Injection attack, hackers can enter a modified
query string in the input box on a web form. By entering a modified SQL
query, the hacker essentially makes a request for information in the
database. The web application is ‘tricked’ into posting a modified
query to the database. The database responds with the requested
information. In this instance, it may not matter if data is encrypted
when it is stored in the database as the database is responding to a
query from the web-application. The hackers can still extract the
information in its unencrypted form. This makes SQL injection
particularly dangerous and of grave concern to both information
security practitioners and regulators alike. The Federal Trade
Commission has already taken action against several online retailers
that were compromised using SQL-injection.
Cross Site Scripting allows a hacker to ‘trick’ a web application into
forwarding malicious script into a victim’s web browser. These
malicious scripts can be used to, among other things, hijack user
sessions, deface websites, or steal application data. According to
Jeff Williams, CEO of Aspect Security, specialists in application
security:
“Cross site scripting attacks are possible on most web applications. In
our experience, well over 80% of reviewed applications are vulnerable
to CSS. There are so many input points, that it is difficult for even
skilled developers to remember to validate every piece of input that
could possibly be sent back to a browser. Many developers validate the
main form fields, but forget about checkboxes, headers, and hidden
fields. In short, this is a very easy attack to perform and difficult
to protect against.”
While it has been said many times that there is no way to render any
network environment impenetrable, there are certainly prudent measures
that can be taken to avoid some obvious pitfalls. Among those methods
is an application code review for any custom web-facing software that
is developed.
PCI Requirement 6.3.7 requires review of all custom code prior to its
release. Before the code is placed on the production environment, the
code must undergo a review to identify potential vulnerabilities.
Generally, the application code review will examine the application for
the vulnerabilities identified as the OWASP
Top Ten. OWASP, or the Open Web Application Security Project, is
dedicated to researching “the causes of insecure software.” In this
endeavor, the organization has compiled a list of the most common coding
vulnerabilities. (More information on the OWASP and the
OWASP Top Ten can be found at www.owasp.org/documentation/topten.html)
Additionally, it is important to understand some idiosyncratic traits
that occasionally exist in the developer community. Some developers
view their work as an art, and so want to leave some sort of signature
in the application. An example of such a signature is what developers
term an “easter egg.” In one example, two developers created a custom
application for a client that contained commands that would display
their pictures and the words “WORLD’S GREATEST CODERS” after a
particular sequence of keystrokes had been entered. In other cases,
coders will leave “backdoors” in the code that will allow individuals
to easily access an application while bypassing all authentication
methods. Generally this is done to ease the way for testing and
“fine-tuning” the application. While this may seem innocuous, the
existence of such easter eggs and backdoors represents significant risk
to the data being handled by the application.
In order to address the matter of application security, Visa USA
developed the Payment Application Best Practices or PABP. The PABP is
meant to provide guidance to developers for the protection of account
data. There are 13 best practices defined by Visa. They are:
- Do not store magnetic stripe data
- Protect stored data
- Provide secure password features
- Log application activity
- Develop secure applications
- Protect wireless transmissions
- Test applications to address vulnerabilities
- Facilitate secure network implementation
- Cardholder data must never be stored on a server connected to the
Internet
- Facilitate secure remote software updates
- Facilitate secure remote access to application
- Encrypt sensitive traffic over public networks
While the card association does not mandate these practices, many of
them are based on the PCI requirements. For example, the first best
practice, “Do not store magnetic stripe data,” is also PCI requirement
3.2 which prohibits companies from storing sensitive data including
magnetic stripe, CVV2 data, and PIN Verification Values. Visa has
posted a list of applications that have successfully undergone an
evaluation against their PABP. The list can be found on the Visa USA
website.
As with network and security architecture, there is no way to ensure
that all applications are completely impenetrable. The key, as with all
security, is to mitigate the risk to the application. Until now, the
web application has largely been overlooked as a security vulnerability
for e-commerce companies. Much of the focus, until this year, has been
placed upon the correct configuration of servers, network architecture,
policies and similar information security solutions. However, ignoring
the application in the security equation is somewhat akin to locking
the front door, but leaving the window open.
|
