Web Site Security for Catalogers

Be afraid. Be very afraid. As you read this, hackers are scanning your servers for open ports. Or perhaps at this moment a hacker is pasting odd strings into your catalog request form to steal credit card numbers. Worse yet: Your machines might already be compromised — and you don’t even know it.

Yes, my intent is to scare. And yes, I sound paranoid. But I’m actually not.

As one security expert told me with no trace of humor, “It’s not paranoia when they really are trying to get you.”

As a multichannel merchant, your days should be spent worrying about merchandise, customer satisfaction and postal increases. But in this column I’ll suggest that as a cataloger, you must understand the all-too-real business risk of Web attacks, and then take steps to reduce that risk.

On language: Computer cognoscenti use “hacker” as a compliment, meaning a programming wizard. But I use the more common meaning: “a person who illegally gains access to and sometimes tampers with information in a computer system.”

First, I’ll dispel three myths. Then I’ll offer five tactics for making your Web site more secure.

Three Myths Dispelled

1. Ours is a small company. We have no enemies, so we’re not much of a target. Hopefully, your company doesn’t have serious enemies intent on your destruction. But some companies do. For example, the SCO Group is routinely targeted by hackers for their legal claims to Linux.

Even if hackers aren’t specifically going after your site, you’re still a target. Hackers covet your resources: (e.g., bandwidth, mail server, customers’ credit card numbers). Just as an addict may rob for drug money yet hold no personal ill-will towards his victims, so hackers attack sites without malice, rather simply to steal resources.

2. Our Web site isn’t really complicated, so it’s probably safe. Even the simplest Web site allows the public access to one of its servers. To serve up Web pages, a computer must listen to the outside world and respond. So by definition, Web servers are exposed, and exposed machines face risks. Are you sure your servers are locked down, patched and secure?

Moreover, if your Web site has a database behind it (and most do) the risk is even greater. Less-than-perfect coding exposes you to possible SQL injection attacks described below. Your seemingly simple site likely isn’t. Again, this increases your risk.

3. We’ve outsourced our site’s applications and hosting, and the vendor has this problem covered. When outsourcing, you still bear responsibility for ensuring your outsourcing partner follows security best practices. (Some are described below.) Know what questions to ask, and make sure you like the answers. The responsibility for security ultimately is yours.

Five Security Strategies to Adopt

Following are security tips and take-away “executive questions” to ask your IT team or outsourcing partner.

1. Security isn’t a product. It’s a process. It’d be easy if you could buy something to ensure your site was safe. But you can’t. Security is an ongoing process that involves all aspects of your company, and the threats continually are evolving.

When you make decisions on site functionality or technology, always ask about the security implications. Jeff Cornejo of Blue Ridge InternetWorks, a firm helping catalogers secure their Web sites, suggests: “Whenever you make a decision about your site, the first question to ask is, ‘How will this affect the bottom line?’ And the immediate second question should be ‘How will this affect site security?’”

Executive Questions:

Who in our organization has responsibility for ensuring our Web site is secure?

What training have they had on this topic?

When was our last site-security review?

2. Patch your server’s operating system regularly. Whether your Web server runs Microsoft, Linux or something else, update its operating system (OS) with the latest security patches lest hackers exploit any well-known vulnerabilities. Some patches fix recently discovered holes in operating systems. Others apply to certain products.

To give some sense of the speed of onslaught: A security expert I spoke with said if you placed an unpatched version of MS SQL Server 2000 on a Web server, it would catch the well-known “SqlSlammer” virus from the Internet — within five minutes!

The SANS Institute is a valuable resource for Web security. Each Monday SANS publishes a free newsletter called @RISK, summarizing the worst vulnerabilities detected the past week, and the correct response to protect yourself.

Executive Questions:

Do we maintain our own Web servers, or do we outsource them?

Who is responsible for patching our server OS?

How frequently do we apply patches, and when did we last patch?

Who monitors the weekly SANS vulnerability alerts? And who covers when that person is on vacation?

3. Turn off every port and service that you don’t absolutely need. A “service” is a program that allows a computer to serve Web pages, send or receive mail, etc. A “port” is a channel on which a server listens and talks to the outside world.

Many operating systems turn on unneeded services by default. For example, unless explicitly told otherwise, a newly installed server may leave port 23 open for telnet, and port 21 open for FTP.

Every open port and service exposes you to more risk. Turn off everything that isn’t needed.

Free tools are available to help you determine which ports are open on your machine. (Indeed, hackers use similar tools to probe your network.) Free tools include: Nessus (http://www.nessus.org), Nmap (http://www.insecure.org), and Security Auditor’s Research Assistant (http://www-arc.com/sara).

Executive Questions:

Have we locked down optional ports and services?

Have we scanned our own machines to make sure?

4. Protect against SQL injection attacks. You’ve probably heard of Structured Query Language

(SQL), the lingua franca of relational databases.

If you’re running an e-commerce site, there’s likely a database involved. Each time a visitor browses a product page, the pricing, copy and image likely are pulled from one of your databases. Each time a visitor adds something to a cart, signs up for your e-mail or requests a catalog, the information is pushed into one of your databases.

And there’s the rub: Visitors have a channel to talk to your database. If the Web site is coded carefully, there’s no problem with this — the site needs its database to provide and receive information. The problem is, sometimes Web sites aren’t coded carefully. In such cases, hackers can paste sneaky characters into your forms or URLs to run commands against your database. This could let them use your database in ways you didn’t intend. An SQL injection attack is pushing code into a slot where your system expected data.

A hacker constructs a special string containing unusual characters (e.g., quote, apostrophe, percentage), plugs the string into a form on your site and thus gains control of your database.

For an example of this, read Steve Friedl’s essay at http://mvp.unixwiz.net/techtips/sql-injection.html, or Chris Anley’s technical suggestions at www.nextgenss.com/papers/more_advanced_sql_injection.pdf.

Automated tools facilitate SQL injection attacks. To expose this vulnerability, Application Security published DataThief (http://”www.appsecinc.com/resources/freetools) an SQL injection wizard aimed at MS SQL Server.

What could hackers do once inside your database? They probably could view and destroy private data. Worse, pernicious hackers could export the database in its totality to a remote server under their control.

While companies protect their database servers from inbound attacks, fewer restrict their databases from making outbound requests. (Database administrators like outbound access to download patches.) Some database platforms offer convenient replication functions to copy a database from one server to another, and hackers have used this capability to move corporate data en masse to off-shore havens.

Executive questions:

Is our site secure against SQL injection attacks? How do we know?

Can our database servers send information out across our firewall? If so, could we turn off this outbound access?

5. Follow credit card security guidelines. MasterCard and Visa provide guidelines for merchants on network and credit card security. Visa’s guidelines, called the Cardholder Information Security Program (CISP), provide explicit instructions on best practices for safeguarding your data.

To get the CISP guidelines, search for “PCI self-assessment questionnaire” at http://usa.visa.com.

The guidelines offer best practices to harden your routers, servers and databases against hackers. For example, encrypt credit card numbers immediately upon collection, store credit card numbers in your databases in encrypted format, and decrypt numbers only when needed for processing. The guidelines also require the CVV2 field never be stored.

Executive Questions:

How compliant are we with CISP guidelines?

Where do we store credit card numbers?

How exposed are those machines?

Do we store credit card numbers in the database encrypted or in plain text?

Do we store CVV2 numbers?

Conclusion

Web site security is a huge topic. This article merely scratches the surface. An expanded list of references and links is available at www.rimmkaufman.com/catalogsuccess/security. However, security is a complex technical challenge, and an area where expert advice is well worth the expense.

As a merchant, you must understand your Web attack risk is real and significant. Your site probably is vulnerable, and it’s definitely a target. Ignoring this issue threatens your site, brand and customers. May your fear drive you to action, and may your actions safeguard your site.

Alan Rimm-Kaufman, Ph.D., leads the Rimm-Kaufman Group, a firm providing search marketing services and e-commerce consulting to leading catalogers and store retailers. He can be reached via his Web site, www.rimmkaufman.com.