In the realm of PCI, the network of independent agents might not be so independent after all. When one thinks of agents, one thinks of real estate, insurance and travel. They all provide a service, they all take information, and they all accept payments. Some of these are independent agents who own their own agency and are affiliated with a larger organization. The larger organization may or may not also have company-owned branches of its own. At the branches, the agents are generally company employees. At the agencies, they are employees of the agency. Indeed the agency itself is a separate entity from the company. It may be a franchise, or a completely independent business that licenses the company’s name. In addition to Realtors and insurance agents, a number of other companies come to mind - cleaning/maintenance, pest control, and pack-and-ship agents that resell courier services. Indeed it is easy to find many of these agencies in our communities. What are the broader consequences on payment card security, from a corporate, agency and consumer perspective? What would happen if a breach of cardholder data were to occur at one of these agencies? Who would be responsible?
Several architectural models exist for integrating agents into the provider network. An agency may be treated as a virtual branch office, identical to any of the company-owned offices even though the facility, its employees, and its operations are not the company’s own. The company’s IT department might deploy company systems in these agent offices, with full connectivity back to the corporate offices. Each agency employee is treated like a company employee and enjoys similar information access. The independent agency may have operational practices that differ considerably from that of the company’s corporate environment, and these practices may vary greatly from one agency to another.
For example, the company might have adopted a cardholder data retention policy that is strictly enforced in the corporate office, but unheard of at the agency. The corporate office avoids storing hardcopy containing cardholder data while the agency may make their customers fill out paperwork that includes credit card account information. These documents are stored in a file cabinet at the agency. In addition to the agency being unaware of the corporate data retention policy, the same agency is also unaware of a media disposal policy that exists and is practiced at the corporate office - and that calls for shredding of the hardcopy documents when no longer needed. The agency simply throws them in the trash, having never thought about this. Nor should they - they are not the company, they are not in the corporate environment; they are an independent agency, a completely different entity.
Knowing this, part of the contract between the corporation and the agencies might establish specific operational guidelines or might mandate adherence to corporate procedures for all agencies that choose to affiliate with the company. In the face of full corporate responsibility for operations at all of its agencies, this is almost a given for any company with independent contractors, where the lines between home office and agent office blur. When and where a breach occurs might be difficult to sort out, making it difficult to determine where responsibility lies for both parties.
The blurring of operational lines often induces corporations to seek out one of two other models - remote partner model or payment gateway model. In the former, the corporation rolls out its application to the agency using a remote access methodology. This may take the form of a web-based extranet or a client-server model. In the latter, the agency is fully responsible for accepting all payments, but leverages the partner corporation for payment processing.
The advantage of the remote partner model is that the corporation rolls out remote access to its systems to the agents, but retains full control of the operating environment. The line of responsibility between the environments is well defined. For the agency, entering payment information into the “corporate system” frees it from storage, retention, and disposal requirements and obviates the worry for systems operations. For the corporation, there may still be aspects of the agency’s operations that are beyond its control, but its exposure to the risk of data compromise at the agency is limited.
When the corporation-agency relationship uses a payment gateway model for payment acceptance, the agency assumes a greater operational role in the processing of cardholder transactions. The systems are independently owned and operated, as is the agency itself, and payments (of insurance premiums, for example) are made to the agency, not directly to the corporation. In turn, the corporation provides authorization for cardholder transactions to the agency. The transaction belongs to the agency, and it is the agency’s responsibility to secure the cardholder data collected.
Finally, the implication for both parties is this: the corporation (such as the insurance company) may need to be audited as a payment gateway as well as a merchant as part of the PCI process, but the agent environment would be fully out of the corporation’s scope for PCI compliance. The agency as a fully independent organization may need to complete an SAQ or a ROC, depending upon its cardholder transaction volume and its Acquirer. It also means that the agency assumes full responsibility for any breach of cardholder data that occurs at the agency.
I like to watch industries evolve in how they deal with information security. It was interesting to watch retail evolve as PCI got more organized. The PCI Council put together the DSS with dates and penalties for breaches and non-compliance, and that drove significant change. It appears that a similar major change within healthcare is starting to take place. We have begun to see a proactive shift that incorporates compliance with HIPAA, an understanding of risk, and the development of security programs.
As I’ve discussed in the past, the healthcare industry is significantly behind in dealing with IT-related risk. For an industry to change its approach to information security / risk, its culture needs to evolve. In my opinion, risk is the most effective driver of this change. If the risk is great enough, industries develop a mature understanding of risk management (of which security is a subset). The military and banking have tangible risks tied directly to their IT assets; therefore, they understand risk. The problem is that this mature understanding of risk doesn’t exist in most other industries. Without risk driving a security program, industries must rely on other drivers - usually compliance (also a subset of risk).
What we’re seeing within healthcare is that PCI is driving the maturation of risk. For example, one key issue that keeps coming up, especially in hospitals, is the belief that PHI is more important than PCI / credit card information. Yet it is PCI compliance that has forced organizations to think systematically about risk. How do you reconcile the budget for PCI compliance with the lack of budget for PHI-related security?
In addition, PCI has forced multiple groups (including IT, security, audit, and finance) to work together to deal with compliance and, ultimately, information security issues. Many of these same groups are now being asked to deal with HITECH / ARRA / updated HIPAA. With the new interpretations of HIPAA, the new regulations, and with these new sets of eyes, these groups are beginning to understand that they are not compliant with HIPAA, that they have significant risk exposure, and that they need to develop programs to deal with this exposure.
From what we are seeing with many of our healthcare clients, the combination of a more pervasive awareness of PCI and new healthcare-specific regulations are creating a more mature understanding of risk and driving a new focus on developing successful information security programs. Let’s hope this trend continues.
As an information security professional, my experience within the payment card security industry has taught me that credit card fraud is not just an information security or information technology issue, but increasingly also a financial one.
In order to process payment cards, organizations must execute agreements with financial institutions (”acquirers”) that legally obligate them to put in place appropriate controls to protect the underlying data. In most organizations, it is the finance and accounting teams that are most familiar with the business processes involved with the acceptance, chargeback and settlement of credit card payment data. Therefore, it is very important that the CFO and finance teams be involved in any effort to construct a sound credit card security program or approach. Such a program should seek to both minimize the risk and the cost of compliance.?The payments community has learned that stolen credit card data is a valuable commodity among criminals; just ask the folks at TJX or Heartland Payment Systems, where breaches resulted in the exposure of credit card data for millions of people.
PCI DSS
The compliance requirements (and the fines for noncompliance) are starting to be pushed down from the credit card companies to financial institutions or acquirers who are, in turn, pushing down to their customers (”merchants” and or “service providers”), contractually requiring organizations to become PCI-compliant. Organizations that have one acceptance channel for credit cards (e.g., a POS or via the web) and use third-party software should self-assess via the Self Assessment Questionnaire (SAQ). Financial professionals should use the published prioritized approach from the PCI Security Standards Council (SSC) to address specific risk areas within their organizations regarding credit card data. Those organizations that have multiple acceptance channels (storefront, Point of Sale and/or via the web) and that store credit card data should involve a Qualified Security Assessor (QSA) if assistance is needed.
Upcoming dates for the standard
There are two important PCI-related dates that are fast approaching, which finance people should be aware of.
July 2010 marks the date after which all merchants must use certified payment applications. A payment application is any application that accepts, transmits or processes credit card data. An example of a payment application is a card swipe machine at a grocery store or a pay at the pump application at a gas station.
September 2010 involves the PCI DSS itself, which will have updates to the standard released that month. These updates will take effect in January 2011.
I am currently on my way back from Las Vegas and the PCI (Payment Card Industry) Assessors Meeting. I guess it is appropriate that the Delta flight that I am on is a cashless flight; you are now able to buy all the $5 Pringles you can eat with a credit card. But I digress; the real update here is regarding the PCI Assessors Meeting that I attended Thursday afternoon. In all there were approximately 30 representatives of QSA (Qualified Security Assessors)/ASV (Approved Scanning Vendors) companies in attendance. The event was not well attended from the perspective of many people that I spoke with, some attributing the lack of attendance on the session not being well publicized.
The meeting provided a summary of the last couple of months within the payment card industry. The monthly newsletter was discussed as well as the relevance of topics covered within the newsletter. Evidence gathering and how evidence is verified provided some information on the top 10 areas for improvement for DSS (Data Security Standard) and PA-DSS (Payment Application - Data Security Standard). Speaking of the PA-DSS, it was reported that there has been a 17% increase in the number of the ROVs (Report on Validation) being submitted. The recently released ASV Program Guide was summarized during the meeting, including the new reporting templates.
The question and answer session lasted longer than the presentation and covered a broad area of topics. There were questions related to assessment methodology and the need to have consistency in approach amongst the QSA firms. The QA Program will be updated in the fall to coincide with the update to the DSS. The updates or potential updates to the standard where not discussed as the card brands and the SSC (Security Standards Council) want to make sure that they adhere to the feedback lifecycle timelines that have been established.
Overall the meeting would have been better received if there was more information provided regarding the proposed updates to the DSS. However, the card brands and the members of the SSC were willing to engage in productive conversation that will benefit the standard in the long term.
As an organization that performs a large volume of code reviews and penetration tests, NetSPI is frequently asked which type of application assessment is the best option. Your primary options are a code review or a web application penetration test. Both are recommended and both find many of the vulnerabilities commonly found in web applications as defined by the Open Web Application Security Project (OWASP) Top 10 (http://www.owasp.org). By themselves, neither a code review nor a web application penetration test find all of the vulnerabilities that threaten the application.
Why perform them?
Many regulations either require them or highly recommend them. For example, Payment Card Industry Data Security Standard (PCI-DSS) requires that either a code review or a web application vulnerability security assessment (web application penetration test) is performed annually on any web application that stores, processes or transmits credit cards (PCI Requirement 6.6). In addition, for payment application vendors (i.e. point-of-sale application, etc.) the PCI Payment Application Data Security Standard (PA-DSS) requires a code review and a penetration test targeting the OWASP Top 10.
Picking one over the other
Even though code reviews and web application penetration tests can find most of the same vulnerabilities, they look at the application differently and as a result their findings can differ. Typically both approaches find OWASP Top 10 issues such as SQL Injection, cross-site scripting (XSS), etc. However, the efficiency and effectiveness how each method finds these vulnerabilities can differ. For example, code reviews are better at finding most instances of input validation issues (i.e. XSS or SQL Injection). All of the automated code scanning tools NetSPI uses trace the data within the application from its entry point to its exit point. A web application penetration test can find these instances but it could take days or weeks to prove they exist in the application.
Web application penetration testing
A web application penetration test can uncover vulnerabilities from the outside looking in. These vulnerabilities can be related to configuration or versions. An example might be an older version of Apache with a chunked encoding overflow vulnerability (http://osvdb.org/838). Web application penetration tests can also uncover vulnerabilities that are related to the operation of the application, such as default or easily guessed credentials. Other types of vulnerabilities found by a web application penetration test include:
Access control (forced browsing, etc.)
Session hijacking
Vulnerabilities related to business logic
In addition, web application penetration testing can find these instances easier than a code review. This being said, I am talking about a third-party code review, not a code review done by a person or person familiar with the code or the company’s development processes. Automated source code analysis tools do not find these types of vulnerabilities. Manual testing can be done but could greatly inflate the cost of the code review.
Code Reviews
A code review looks at the application from the inside out. Vulnerabilities commonly found in a code review that cannot be easily found in an application penetration test include logging of sensitive data or application backdoors, as they are not exposed to the outside. Other types of vulnerabilities found by a code review include:
Denial of services caused by not releasing resources
Buffer overflows
Missing or poor error handling
Dangerous functions
Hardcoded password or keys in the source code
Code implementation problems
Missing or poor logging
Look at the statistics
NetSPI has found through our own experience that only a small subset of vulnerabilities found by code reviews and application penetration tests overlap. In NetSPI’s analysis, only 18% of the overall vulnerabilities found were discovered in both the code review and the web application penetration test where both services were performed on the same application (see Code Review Percentages pie chart below). Of the vulnerabilities found in the web application penetration tests, only 14% of the findings are found by both the web application penetration test and a code review (see Pen Test Percentages pie chart below).
Final Thoughts The most comprehensive approach to finding security vulnerabilities in web applications is performing both a code review and a web application penetration test. For critical applications, performing only one of these services can result in many vulnerabilities remaining within the application and unacceptable risk to the organization.
Subscribe