tummy.com has accepted Discover cards for as long as we've been in business. Today, in their email newsletter, Discover is promoting having a security company to do regular security reviews of merchant websites.

One of the things we've always been concerned about is security, both of our own systems, and those of our clients.

Here's how tummy.com stacks up against the 10 critical factors for ensuring security of credit card data recommended by Discover and Ambiron:

1) Do not store CVV and/or Discretionary Data subsequent to Authorization.

tummy.com never stores this information, and we recommend our clients never store this information either. All payment information is never stored on disc or transmitted in unencrypted form. Internally we use 2048-bit PGP encryption for this data.

2) Conduct remote network vulnerability scanning and conduct penetration testing and on-site vulnerability assessments.

tummy.com does remote scans using nessus and netsaint when requested by our clients. We rarely do on-site vulnerability assessments, because most of our clients practice appropriate levels of physical security including locking doors and regulating access to server facilities.

3) Card data that is stored or transmitted must be done so in an encrypted fashion (CID never stored).

tummy.com uses several different layers of encryption for transmitting sensitive data over the Internet including OpenVPN for creating a secure channel, and PGP encrypted email for ensuring for-your-eyes only messages.

We recommend a similar level of encryption for all of our clients, as it is easy to setup and maintain on Linux, and provides good end-to-end security. This is especially important when accessing sensitive information over insecure channels, such as wireless networks in public places.

4) Card data can not reside on any Internet facing systems. These systems must be functionally segmented.

tummy.com does not store credit card information on any publicly accessible systems.

For our clients, we often set up a DMZ (de-militarized zone) system, with public services like email and web servers, on a separate subnet from the internal LAN. An alternative is to have email and web servers hosted at a separate facility. That way an attempt to gain access to more sensitive services through an attack on an email or web server will have a harder time succeeding. All Internet facing systems have special security requirements, and those that handle sensitive client information require the highest level of care.

5) Utilize a firewall with stringent and granular security rules at all points of entry. Intrusion detection/prevention systems should be strategically placed within the network as needed.

tummy.com believes that every system needs to have strong firewall rules, not just ones you've identified as points-of-entry. Those firewall rules must be verified and reviewed regularly.

An example from a presentation at a local Linux users group was from NOAA. They thought that because they had firewalls all around the network they could just never patch or setup firewalls on internal machines. They now require patches be applied to ALL machines and that even internal machines have firewalls.

In our experience, we haven't found intrusion detection systems to be helpful in the majority of cases. They generate a lot of data, which needs to be manually reviewed. For the majority of our customers, the time and expense involved in manually reviewing intrusion logs would be better spent doing regular patches, log reviews and audits. It's a trade off between managing the likely, preventable risks versus the less likely less manageable risks.

Intrusion detection systems will tell you that your systems are being scanned on an nearly continuous basis. But, that information isn't useful unless you can do something about it, and only the largest companies have the resources to devote full-time staff to tracking down and reporting scan attempts to the appropriate authorities. The good news is that large ISPs like Earthlink and AOL do spend a lot of time and effort doing just this.

Tools like Tripwire and snort, which monitor changed files, can be effective, if they are tuned properly, and the alerts regularly reviewed.

We also use other tools like chkrootkit and Rootkit Hunter, for identifying the signatures of exploits, and the rpm database package integrity tests, for identifying changed binaries. But we use them when there are signs that there is a problem, not on a preventative basis.

An analogy is that your doctor doesn't recommend you get a CAT scan every day. Sure, they'd find a lot of stuff which may be wrong with you, but it would be terribly expensive, and you may not actually become healthier because of the tests. The result may actually be that you have a lot of marginally necessary medical procedures done, which all carry a risk of reducing your health.

For our clients, we recommend they pursue the most effective tasks first, and only pursue the more exotic when their needs dictate it.

We set up and maintain strong firewalls for our clients. Additionally, we encourage them to have us review their firewall rules on a regular basis.

6) Verbose logging must be enabled on all security devices and services that facilitate Card data. Analysis of the logs and system statistics should be reviewed regularly.

tummy.com's policy is to consider all computers as 'security devices', not just the Internet-facing firewall. We enable logging on all systems and review them regularly.

We encourage our clients to have the same view. There are some automated tools for reviewing system logs on Linux like logwatch or epylog. Logwatch ships with KRUD and Red Hat/Fedora. It generates a report which is mailed daily. We encourage our clients to use these tools, and to have us conduct regular log reviews. Even on well maintained systems, log reviews can identify unanticipated problems, like unauthorized access attempts, problems caused by package updates or patches, or unusual usage patterns. Log reviews are one of the easiest things for a busy person to put off, yet are an important part of maintaining security. We also recognize that having an external organization conducting log reviews is a way of providing a checks-and-balances review of your system administration processes.

7) Utilize build/patch, change control and incident response policies built on industry standards.

The security organization CERT offers many documents on security standards. tummy.com reviews these standards regularly and incorporates them into our practices.

Incident response policies depend a lot on the requirements of the system. High uptime requires different approaches than systems with a lower dollar/per hour of revenue. Legal considerations, such as evidence preservation, are also factors to be considered. We tune our incident response methods to the needs of our individual client's systems.

8) User-level access should conform to an industry standard password policy. All remote and administrative access must be encrypted.

tummy.com uses SSH keys, not passwords for remote and administrative access. One of the most sensitive times for security is during a change in personnel. Passwords are impossible to revoke out of someone's head, while an SSH key is easily removed. Additionally, SSH key authentication with ssh-agent is not vulnerable to trojaned intermediate systems sniffing passwords.

We recommend our clients also use SSH for all remote access. Further, we recommend that "telnet" and "rlogin" and other similar un-encrypted access mechanisms be completely disabled. SSH is easy to set up and maintain on Linux, and provides a small performance increase on the transmission speed. Wherever practical, we also recommend POP and IMAP in particular be SSL encrypted, and (to a slightly lesser extent) SMTP.

9) Wireless access points (WiFi, 802.11, etc.) must require authentication and encryption.

tummy.com believes the encryption available on most Wireless Access Points is inadequate. WEP keys may be easily cracked, and provide only an minimal security. A strong VPN is a better solution, as it provides end to end security no matter where you connect from. The Internet is also often easily "tapped" by administrators and intruders into systems at every hop along the way. It doesn't matter if the data goes through the air, or over copper wires or fiber.

We recommend our clients have a skeptical view of how secret their data is over the public Internet, and to use encryption wherever they can. It is easy to implement, and cheap protection.

10) Systems that store and/or transmit Card data must utilize current anti-virus software.

tummy.com runs Linux, which is not vulnerable to many viruses. We filter our incoming email for viruses, and apply regular patches to all of our systems. We also closely monitor the network activity on our hosted client and our own systems for signs of unusual activity.

For many of our clients, who are still running Windows systems, we recommend they use anti-virus and other system cleaning software regularly. On our client's Linux servers, we regularly apply security updates, blocking security holes as soon as the fix is available.

Keeping up with security is a lot of work, and it requires constant attention. It's a big part of the reason we provide managed dedicated hosting. Just this week, Kevin applied 3 separate security updates which blocked both local and remote attacks. It's also the reason we provide a regular system updates and log review packages for our clients.

We'd be happiest if our clients never had a security problem. We all do our best to make sure that happens. For those clients that we provide the majority of their system administration for, I'm happy to say that they rarely if ever have security problems.
(Post Reply)