The PCI SSC (Council) is responsible for managing the security standards, while compliance with the PCI set of standards is enforced by the founding members of the Council: American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc. Non-compliant companies who maintain a relationship with one or more of the card brands, either directly or through an acquirer risk losing their ability to process credit card payments and being audited and/or fined.

All in-scope companies must validate their compliance annually. This validation can be conducted by Qualified Security Assessors, i.e. companies that have completed a three-step certification process by the PCI SSC which recognises them as being qualified to assess compliance to the PCI DSS standard. However, smaller companies have the option to use a Self-Assessment Questionnaire. Whether this questionnaire needs to be validated by a QSA depends on the requirements of the card brands in that merchant’s region.

The current version of the standard specifies 12 requirements for compliance, organised into 6 logically related groups, which are called “control objectives.”

1. Build and Maintain a Secure Network
   • Requirement 1: Install and maintain a firewall configuration to protect cardholder data
   • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
2. Protect Cardholder Data
   • Requirement 3: Protect stored cardholder data
   • Requirement 4: Encrypt transmission of cardholder data across open, public networks
3. Maintain a Vulnerability Management Program
   • Requirement 5: Use and regularly update anti-virus software
   • Requirement 6: Develop and maintain secure systems and applications
4. Implement Strong Access Control Measures
   • Requirement 7: Restrict access to cardholder data by business need-to-know
   • Requirement 8: Assign a unique ID to each person with computer access
   • Requirement 9: Restrict physical access to cardholder data
5. Regularly Monitor and Test Networks
   • Requirement 10: Track and monitor all access to network resources and cardholder data
   • Requirement 11: Regularly test security systems and processes
6. Maintain an Information Security Policy
   • Requirement 12: Maintain a policy that addresses information security

Compliance with these requirements can be summarized into 3 main stages:

• Collecting and storing: Secure collection and tamper-proof storage of all log data so that it is available for analysis.
• Reporting: Being able to prove compliance on the spot if audited and present evidence that controls are in place for protecting data.
• Monitoring and alerting: Have systems in place such as auto-alerting, to help administrators constantly monitor access and usage of data. Administrators are warned of problems immediately and can rapidly address them. These systems should also extend to the log data itself –- there must be proof that log data is being collected and stored.

What does this actually mean for web application developers?

It is considerably more expensive and more time-consuming to recover from a security incident than to take preventative measures ahead of time. If you follow the guidelines below, you will go along way to securing you application in line with the PCI DSS regulations. Many of the measures apply to general application security, but since PCI DSS is all about security, they are worth mentioning.

Server-level Security:

• Separate web- and database-servers on to different physical machines.
• Secure the web- and database-servers with traditional techniques. Only authorised accounts should have the capabilities to run tasks on the machine. That means not giving admin-rights to the user account.
• Keep servers up-to-date with the latest patches and software releases.
• Minimise the number of services running on the server. This means limiting the services to only those required for the web- or database-servers to function.
• Secure information in transit between servers. This may mean physically securing the network to prevent evesdropping via encryption or obfuscating the data amongst innocuous ‘noise’.
• Secure the database server behind a firewall.

Application-level Security:

• Separate ColdFusion, the webserver and database server user accounts. They should never be under the same system account.
• Create a database user specifically for your ColdFusion datasource and restrict it to only the activities required for the application. The user should not have database-owner rights, access to databases not relating to the application or access to the system tables.
• Revoke privileges in the ColdFusion datasource definition to prevent the SQL commands CREATE, DROP, GRANT, REVOKE and ALTER.
• General settings in the ColdFusion Administrator:
  • Check the Disable access to internal ColdFusion Java components option.
  • Check the Enable Global Script Protection option.
  • Add a Missing Template Handler.
  • Add a Site-wide Error Handler.
  • Reduce the Maximum size of post data from 100MB.
  • Enable Timeout Requests, and set to 60 seconds or less.
  • Disable Robust Exception Handling on production servers.

Web Application-level Security:

• Use secure HTTP to transfer data and/or when logged into ‘administration’ secutions of your web application.
• Timeout sessions after 15 minutes and on browser close.
• Provide multi-level login processes. For example, lock the application after 3 failed attempts for a period of 10 minutes.
• Do not identify whether the username or password are incorrect, simply notify the user that their login failed and that they must try again.
• Encrypt passwords stored in the database with a standard such as SHA-256 or ‘stronger’.
• Use CAPTCHAs (textual and aural) to prevent automated robots hacking into your application.
• Run regular penetration tests on your application to identify potential problems.
• Encrypt credit card information held in the database or other storage mechanism. Only store credit card data in line with the PCI DSS regulations.

Code-level Security:

• Application.cfc – Set the scriptProtect Application variable to true to enable application-wide cross-site script protection.
• CFQueryParam – This tag, importantly, verifies the data type of a query parameter and, for RDBMSs that support bind variables, enables ColdFusion to use bind variables in the SQL statement. Bind variable usage enhances performance when executing a cfquery statement multiple times. There are limitations to the use of the cfqueryparam tag. In ColdFusion 7 for example, you cannot use them in queries using the cachedWithin attribute. Similarly, they cannot be used in ORDER BY clauses, although the use of conditional logic should resolve the need for order by variables.
• Functions – As a rule of thumb, validate all the data being passed into a query prior to it being used. ColdFusion MX 7 saw the introduction of the isValid() function. This function tests whether a value meets a validation or data type rule and can be used to replace a large number of type-specific functions such as isArray(), isBinary(), isBoolean(), isDate(), isNumeric() and isSimpleValue() etc.
• Stored Procedures – I often favour the use of stored procedures over standard queries. Not only do they add an additional level of performance, they provide an additional level of security; ColdFusion does not do any raw processing of queries in the web code, it simply passes variables down the wire to the database server.

Conclusion

The goal of the PCI Data Security Standard is to protect cardholder data that is processed, stored or transmitted by merchants. The security controls and processes required by PCI DSS are vital for protecting cardholder account data, including the PAN – the primary account number printed on the front of a payment card. Merchants and any other service providers involved with payment card processing must never store sensitive authentication data after authorisation. This includes sensitive data that is printed on a card, or stored on a card’s magnetic stripe or chip – and personal identification numbers entered by the cardholder.

By following the points made above, you will go a long way to meeting the PCI DSS guidelines, whilst also securing your infrastructure and applications in a more general sense.

Caveat: The views and comments written in this article are provided as a guideline. I hold no responsibility for the security of your applications and data based upon the information provided.

Social network portability is one of several user-interface ideas and suggestions in the area of data-portability. As users, our identity, photos, videos and other forms of personal data should be discoverable by, and shared between our chosen (and trusted) tools or vendors. When you join a new site, you should be able to import or preferably subscribe to your profile information and your social network from any existing profile of yours. We need a DHCP for Identity. A distributed File System for data. The technologies already exist, we simply need a complete reference design to put the pieces together. This problem is solved by a number existing technologies and initiatives: Microformats, OpenID, OAuth, RDF, RSS, OPML and APML.

Data Portabilities mission is to put all existing technologies and initiatives in context to create a reference design for end-to-end Data Portability. To promote that design to the developer, vendor and end-user community.

This post serves a brief primer to each of these technologies.

Microformats

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviours and usage patterns (e.g. XHTML, blogging).

Examples include:

People and Organizations

hCard

Calendars and Events

hCalendar

Opinions, Ratings and Reviews

VoteLinks, hReview

Social Networks

XFN

Licenses:

rel-license

Tags, Keywords, Categories

rel-tag

Lists and Outlines

XOXO

If you use Flickr, Technorati, Upcoming, Last.fm, Twitter, Cork’d or any number of other services, you can conceivably share data between the different services providers automatically.

More details can be found on the microformats website.

OpenID

OpenID is an open, decentralized framework for user-centric digital identity. OpenID takes advantage of already existing internet technology (URI, HTTP, SSL, Diffie-Hellman) and realizes that people are already creating identities for themselves whether it be at their blog, photostream, profile page, etc. With OpenID you can easily transform one of these existing URIs into an account which can be used at sites which support OpenID logins.

In other words, OpenID allows users to login using shared credentials across different services. It also allows users to decide what information to share between services. For example, you can allow the use of your address on one service, but not another. You can think of OpenID as an extension to the single sign on used by Google or Yahoo! to access their various services.

More details can be found on the OpenID website.

OAuth

The OAuth protocol is less about authentication, which is the realm of OpenID, but rather authorisation. OAuth is an open protocol to allow secure API authorisation in a simple and standard method from desktop and web applications. For consumer developers, OAuth is a method to publish and interact with protected data. For Service Provider developers, OAuth gives users access to their data while protecting their account credentials.

A number of services have already been implemented. These include Fire Eagle, Open Social, Pownce, Get Satisfaction and Magnolia.

More details can be found on the OAuth website.

Resource Description Framework (RDF)

RDF is a family of World Wide Web Consortium (W3C) specifications originally designed as a metadata model but which has come to be used as a general method of modeling information, through a variety of syntax formats.

The RDF metadata model is based upon the idea of making statements about resources in the form of subject-predicate-object expressions, called triples in RDF terminology. The subject denotes the resource, and the predicate denotes traits or aspects of the resource and expresses a relationship between the subject and the object. For example, one way to represent the notion “The sky has the color blue” in RDF is as the triple: a subject denoting “the sky”, a predicate denoting “has the color”, and an object denoting “blue”. RDF is an abstract model with several serialization formats (i.e. file formats), and so the particular way in which a resource or triple is encoded varies from format to format.

This mechanism for describing resources is a major component in what is proposed by the W3C‘s Semantic Web activity: an evolutionary stage of the World Wide Web in which automated software can store, exchange, and use machine-readable information distributed throughout the web, in turn enabling users to deal with the information with greater efficiency and certainty. RDF‘s simple data model and ability to model disparate, abstract concepts has also led to its increasing use in knowledge management applications unrelated to Semantic Web activity.

More details can be found on the W3C website.

Really Simple Syndication (RSS)

RSS is a family of Web feed formats used to publish frequently updated content including, but not limited to, blog entries, news headlines, and podcasts. An RSS document, which is called a “feed” or “web feed” or “channel”, contains either a summary of content from an associated web site or the full text. RSS makes it possible for people to keep up with web sites in an automated manner that can be piped into special programs or filtered displays.

RSS content can be read using software called an “RSS reader”, “feed reader” or an “aggregator”. The user subscribes to a feed by entering the feed’s link into the reader or by clicking an RSS icon in a browser that initiates the subscription process. The reader checks the user’s subscribed feeds regularly for new content, downloading any updates that it finds.

More details can be found on the RSS Board website.

Outline Processor Mark-up Language (OPML)

OPML is an XML format for outlines. Originally developed by Radio UserLand as a native file format for an outliner application, it has since been adopted for other uses, the most common being to exchange lists of web feeds between web feed aggregators.

The OPML specification defines an outline as a hierarchical, ordered list of arbitrary elements. The specification is fairly open which makes it suitable for many types of list data.

More details can be found on the OPML website.

Attention Profiling Mark-up Language (APML)

APML allows you to share your own personal Attention Profile in much the same way that OPML allows the exchange of reading lists between News Readers. The idea is to compress all forms of Attention Data into a portable file format containing a description of your ranked interests.

Services that have adopted APML include Bloglines, Cluztr, Dandelife, Engagd, Idiomag, OpenLink Data Spaces and Particls.

More details can be found on the APML website.

Securely transfering personal data around the web has become an increasingly important concept to not only users of the web, but service providers. Both Plaxo and Six Apart have been working on a system to allow the transferral of data. However, since Google announce Open Social and the Open Social API, the mantle has been handed over and there is now a strong commitment to realising data portability.