Application Security

For many years, security in and around loyalty systems tended to be somewhat of an afterthought, often being cobbled onto a system after it was built. This is surprising given the fraud potential and liability inherent in loyalty systems. Thankfully over the past few years the awareness of security issues in general have increased dramatically as has the need for improved financial controls.

Security improvements have been driven primarily by the Gramm-Leach-Bliley Act (GLBA) and VISA. GLBA, which applies almost exclusively to financial institutions, was passed in 1999, although the effects relative to security were not really felt for many years. VISA introduced their Cardholder Information Security Program (CISP) in 2001, and subsequently their Payment Card Industry (PCI) compliance requirements in 2004 (and which has now been transitioned to an independent entity).

From my perspective, GLBA’s largest impact relative to loyalty were the security education program requirements that financial institutions had to put in place for their compliance. These programs took the need for security, once championed by only a few, and made it everybody’s responsibility. This had a ripple effect through the industry and required suppliers in turn to become smart about GLBA and the security requirements. The downside relative to GLBA is that it was written in “lawyer speak” and much of what you were required to do had to be “interpreted,” particularly before the Office of the Comptroller of Currency (OCC) provided their examination procedures.

On the other hand, the requirements of PCI are (generally) laid out very clearly, and if you do not understand them, there are resources readily available to help you.

Both GLBA and PCI take a relatively “holistic” approach to security. This approach is necessary because your security is only as good as the weakest control. PCI breaks down the requirements into 12 major areas with detailed questions in the areas of networks and communications, the software development process, data storage, and education, among others. GLBA, as noted above, is more nebulous, even after the examination procedures were provided.

The need for improved financial controls was primarily driven by the Sarbanes-Oxley Act (SOX). Relative to loyalty programs, SOX required end-to-end controls to ensure accurate financial reporting (primarily liabilities). SOX can also be credited with fostering overall process improvements by more-or-less forcing loyalty services providers to obtain a Statement on Auditing Standards Number 70 (SAS 70) Type II auditor’s report. Similarly, organizations subject to GLBA are sometimes required to attain SAS 70 compliance for themselves and often for suppliers that work with non-public personal information (NPPI) and/or have a part in their financial reporting (e.g. program liability).

Note that SAS 70 does not prescribe any specific kind of security or financial controls (in fact SAS 70 does not prescribe anything specifically). Instead, SAS 70 provides a framework for the definition of objectives and controls. The objectives are your desired operating states and the controls are how you confirm that you have achieved them. Relative to loyalty programs, a major control objective is the accurate reporting of liability (the other large major control(s) is(are) around quality service delivery). The liability reporting objective may be broken down into a variety of other objectives that cover point calculations, bonusing setup, reporting, and all the other processes that contribute to calculating point liability accurately. Note that obtaining a SAS 70 Type II certificate can be just as, and perhaps even more challenging than obtaining PCI certification.

The maturity levels associated with application security are detailed in the following table. They range from a low of 0, meaning that essentially everyone has access to everything, to a high of 4, which represents PCI compliance for the application and the environment. While your company or your loyalty system may not be directly subject to PCI requirements, the majority of the requirements represent security best practice (and by implication, financial accountability best practice) and should be considered for implementation.

Maturity Level	Hallmarks
0	Name: None Everyone has access to every function (or most every function) Little or no logging of who has done what
1	Name: Afterthought Shared user IDs Passwords embedded in batch files and elsewhere Few/no rules on password complexity Few/no rules on when passwords must be changed
2	Name: Basic Every user has their own ID Security is implemented by module None to limited assignment by role Good process logging Good logging at the record level Member account access is logged Failed account access is logged Limited consideration to limiting access via tools (e.g. SQL query tool)
3	Name: Advanced Security is implemented by function (e.g. adding an award) Substantial ability to create and tailor roles Strong password complexity requirements Logging at the field level (as required) No passwords in batch files or applications Mechanisms prevent data access from tools Passwords are one-way hashed Key data, such as credit card numbers, is encrypted PCI compliant from the perspective of the application (versus the environment)
4	Name: Enterprise Separate schemas or other mechanisms separate authentication information from data LDAP authentication possible Centralized access revocation is provided PCI compliant from the perspective of the environment

Continued ...