ver 20 software applications have played a role in card data compromises. To counter this vulnerability, 57 vendors have validated 89 payment applications to the Cardholder Information Security Program (CISP).

That number was as of mid-December 2006, according to Martin Elliott, Vice President of Emerging Risk for Visa U.S.A.

Most data compromises occur at restaurants. In response, Visa recently hosted a webinar for restaurant managers, "Keep Data Security on the Menu," to outline steps to protect POS systems from attacks by hackers and data theft by employees or others.

In Part I of this report (The Green Sheet, Jan. 8, 2007, issue 07:01:01), we covered system configurations and measures to segment and protect the POS system from other parts of a restaurant network.

In Part II, we will cover POS host security and a type of database malware known as SQL (Structured Query Language) injection, one of the top five vulnerabilities to payment applications.

Of all the things a restaurant may do to secure its system, maintaining the security of the host is paramount. This begins first with removal of full magnetic stripe data storage, according to Petr Darius, an expert in Visa's Emerging Risk department. Any applications that must store account numbers must do so in an encrypted form, to render them unreadable.

"Assess your business needs to determine if you really need those account numbers," Darius said. "Not having them will limit your liability."

Generally, the POS host should be used only for payment processing, not Web browsing or any nonpayment-related applications.

And only CISP-compliant applications should be used in conjunction with the POS system, "applications that have been vetted," he said. For any application in use, routinely apply the latest security patches, anti-virus engines and signature files.

POS host: the inner sanctum

Access to the host server should be restricted to specific known devices. Using Internet protocol (IP) or MAC (Media Access Control) address filtering is generally an insufficient way to control access because such addresses can be spoofed, Darius said.

Instead, security is best implemented in layers: at all levels within the restaurant network and on all applications and systems, making the inner sanctum of the POS host the most remote and impenetrable.

The more layers hackers must get through, the harder it will be for them to gain entry. Use of the latest version of operating systems and applications will help ensure that built-in security features are up to date.

"If you're using [Windows] NT, upgrade to XP or later. We advise you to upgrade to the latest versions and service packs and enable their security features," Darius said.

And pay attention to security measures on all restaurant PCs not used for transactions. On these, install software-based firewalls, service packs and anti-virus software. (POS systems should be protected by hardware firewalls.)

Finally, implement password management on the host. Centralized password management will make it easier for the restaurant operator to manage the POS environment.

A policy will include passwords for access to operating systems, POS applications, database applications and remote management products.

Database considerations

Some POS applications require database software, known as SQL, which poses a danger to restaurant systems; that danger, called SQL injection, must be managed. Visa is seeing numerous such attacks at restaurants.

"It's basically a common way to attack merchant Web systems and results in significant damage," Darius said. A successful SQL injection can reveal database information and even allow the hacker to destroy data or take over the system.

He noted that input validation is key to preventing such access. When setting parameters for user log-in to the database, restaurants should exclude the use of escape characters or other inputs that exceed normal log-in parameters.

When setting up software applications:

• Always validate user input.
• Avoid dynamic SQL statements.
• Avoid returning full error messages to the client browser.

This last point is important because attackers input invalid phrases, then analyze resulting error messages in an effort to determine the types of tables used in the database.

When installing databases, such as SQL Server, Microsoft Access or MySQL, secure them by protecting accounts belonging to the administrator and power users. The naming conventions on the POS system should be meaningless and obfuscate the nature of the business.

Following these database setup measures will also help prevent unauthorized access:

• Always execute SQL statements under a minimally privileged account, preventing external users from altering fields in database tables.
• Remove unnecessary system-stored procedures.
• Encapsulate SQL statements in stored procedures, if possible (preventing access to database tables).
• Allow only stored procedures to access tables (denying direct access to tables).

An example SQL attack will use a login of "jdoe OR a=a." The a=a can enable the database to return all user records. To prevent this, instruct stored procedures to return only one record per valid login, Darius said.

Other general reminders include changing default passwords on all applications and systems and performing regular scans for known SQL vulnerabilities, Elliott said.

See www.pcisecuritystandards.org for companies approved to perform scans. For a list of validated payment applications, visit www.visa.com/cisp

Visa's Web site also provides reference tools, such as what merchants should do in the event of a data compromise.