ST&E Is the Most Cost Effective Measure for Comply with Payment Card Industry (PCI) Data Security Standard

Abstract

In September of 2006, the five leading payment brands formed an independent council to manage the Payment Card Industry (PCI) Data Security Standard (DSS). American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International saw the need to secure payment account data in a globally consistent manner. As such, the financial institutions which store, process and transact the credit card must comply with the PCI/DSS. The Non-compliance fines can reach up to US $500,000 per incident including the public disclosure of breaches. Financial Institution can implement very broad security controls to comply with the PCI/DSS standard. The cost can be prohibitive. This poster argues that the most cost effective security measure is to conduct a Security Testing and Evaluation (ST&E) project before the expensive auditing performed by a PCI DSS Qualified Security Assessor (QSA) Company. We have proposed 5 distinct phases of ST&E, and what it means to the CIO/CTO of the financial institutions.

The five phases of ST&E are 1) Planning, 2) Develop Evaluation Methods and Tool Selection, 3) Test Execution and Reporting, 4) Corrective Measures Recommendation and 5) Re-Testing.

During the Planning Phase, the scope and rule of engagement is defined, and the requirement of the ST&E is signed off. The scope depends on identifying the mission critical applications which host or process the credit card data. For example, the web server, the application server and database can all be used for processing or storing the credit card information. And the application may have dependency on other applications. So the communication channels between different applications could be the crucial components and are in scope. The rule of engagement identity all stakeholders of the ST&E project, and define the responsibilities of each part involved. A poorly defined rule of engagement would be fatal for the ST&E project.

During the second phase, the testing and evaluation method is defined and agreed upon by all stakeholder involved in the ST&E. The testing method could be black box testing, meaning that the tester has no knowledge of the systems and try different ways to find the security vulnerabilities. Another testing method is the white box testing. During the white box testing, the tester reviews the code and different configuration files, and then constructs the attack methods which could hack into the system. This method is more cost effective and should be used to find the majority of the securities holes in the system.

The third phase is the Testing Execution and Reporting, the testers could use both manual ethnic hacking methods or automated tool to find the security vulnerabilities in the system. Keep in mind that the automated tool can only find very small portion of the vulnerabilities. Thus, the advanced manual ethnic hacking skills are crucial to the success of the ST&E project. After the testing execution, the tester needs to analyze the results to identity the false positives and then produce the report which will be the input to the next phase of the ST&E.

The forth phase is the Corrective Measures Recommendation. If the application impacted is developed in house, the corrective measure could be applied by working with the developers in house. Otherwise, the tester can work with stakeholders of ST&E project to find the appropriate patches from the vendor or report the bug with the vendor if the patch is not available.

The final phase is the Re-testing phase. We emphasize that security testing is not a once and done evaluation. In order to maintain an acceptable level of security, the system must be retested periodically, as well as when the developers make any changes to the system. By developing a reoccurring phase of retesting, Phase Five depends upon the system passing its first ST&E evaluation. Once the system is deemed secure after the initial ST&E, a summation of the results can then be presented to the stakeholders. At that point, the frequency for which the system will be retested can be established.

In this poster presentation, we will demo some common vulnerabilities in the financial applications, such as cross site script attack, SQL injection, weak session management, improver exception handling, and weak encryption. After the demo, we will present in detail the ST&E methodology and how the CTO/CIO can benefit by implementing the ST&E in house, and how ST&E can benefit organizations to achieve the PCI/DSS compliance.