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.
Looking over the findings of the last few dozen PCI gap assessments that NetSPI has performed, I am struck by the fact that today, well into version 1.2 of the Payment Card Industry Data Security Standard (PCI DSS, or just DSS), one of our most common findings remains increased scope due to lack of network segmentation. For example, we have seen numerous merchants with relatively simple payment processing environments that have a very large and complicated PCI scope and must bear the associated costs (e.g., develop and apply hardened system configurations, pay for external scanning services, etc.). In some cases, the merchant may not even have a real business need to store cardholder data (i.e. they could simplify their business processes and complete a Self Assessment Questionnaire C rather than the much longer SAQ D) but, even if they do, the scope of compliance is often far larger than necessary. Limiting the scope of the systems that are required to meet PCI DSS compliance gives merchants and service providers the best “bang for their buck” in terms of reaching their compliance goals, yet it seems that many merchants struggle with defining and implementing the controls necessary to do just this.
The first step in reducing the PCI scope through segmentation is to determine exactly which systems store, process, or transmit cardholder data. While this may be very straightforward for some organizations, it may be helpful to create a cardholder data flow diagram for more complex environments. Once cardholder data systems have been identified, a process of isolation and segmentation can begin. Ideally, cardholder data systems should be segregated off in a “PCI island” by a stateful firewall; Internet-facing systems should be placed in a separate DMZ segment. Once these major changes have occurred, locking down and documenting the firewall ruleset, implementing the necessary management processes, and other items detailed in Requirement 1 are much easier to address.
Though this process may look simple on paper, it can often involve the rearchitecture of not just the network but also individual systems, as PCI-related applications and functions should be isolated from other business functions (e.g., a database containing a parts inventory along with invoicing and payment information should be separated into individual databases in isolated network zones). However, through proper segmentation, merchants and service providers can significantly reduce the cost and scope of compliance and need only apply the DSS to systems and devices that store, process, or transmit PCI data.
As a company, we’ve tried to understand which organizations are most likely to mature their information security programs. It seems that the answer should be obvious: organizations with valuable assets or the need to have data highly available should be very concerned about information security. This could translate into organizations that have a lot to lose, ones that have high profit margins, or those involved with the nation’s critical infrastructure.
Interestingly, this is generally not the case. In fact, the primary drivers for maturing information security within an organization are regulations or contractual standards with strong penalties for non-compliance.
Why is this? One problem is that risk is very subjective. In a downturn, the risk equation can change dramatically. If you are fighting for the survival of a firm, it’s easy to justify not investing in information security. Compliance, however, is not as subjective. While there is room for some interpretation, compliance regulations and standards are stable, detailed, and consistent. This means that compliance is easier to justify, easier to plan for, and easier to assess.
But while meeting compliance standards can be a very good thing, it does create a problem: risk is often left out of the equation. For example, payment card industry (PCI) data often gets more attention at hospital systems than does protected health information (PHI). Based on risk, the patient-related data and services should be classified as at least as important as the credit card information. It usually is not, however. Without a risk-based approach or a strong compliance standard like PCI, PHI won’t get the attention it deserves. (The PHI standards are being tightened somewhat, by provisions of the American Recovery and Reinvestment Act, or ARRA, passed this year by Congress.)
Compliance can help speed the maturation process, and it is valuable in other ways, but it lacks the depth and breadth of a risk-based approach. Additionally, creating regulations and standards for all things that should be secured just isn’t possible. In an ideal world, organizations will take a more holistic, risk-based approach that includes compliance, but this may have to wait until the economy turns around.
Preparing for an audit can be one of the best ways to fund and improve your security program, but this “stimulus package” for your compliance effort typically dwindles once an organization completes or passes an audit. I see this happen frequently in recurring or annual audits, but it is particularly relevant with the recent news of Merrick Bank. Specifically, Merrick Bank is suing Savvis for certifying CardSystems Solutions to be Visa CISP compliant prior to a breach that exposed some 40 million payment card records and resulted in $16 million in fines to the card brands. While this is the not the first breach of a PCI-audited company, it is the first one in which the auditor has been sued. The case raises an important question: Who is ultimately responsible for ensuring that a good security program is in place? Here are some simple, yet critical, points to ensure your security program is driven by something more than the audit itself.
Understand the role of the auditor. When preparing or undergoing an information security audit, it’s critical for organizations to consider the role the auditor performs within a security program. This role should never be a member of your security team or a designer/implementer of your security systems; it must be strictly be a reviewer of your security state at a point in time. While some coaching and direction can be good, all decisions and program enhancements must be driven by the organization itself.
An audit is not a design session. If your security program design is heavily based on the initial audit gap report, your program will not be sustainable. Although you and your auditor share the same goal, ensuring you are compliant, your auditor’s coaching will be targeted on one thing—meeting a specific requirement. Your program will then also be designed merely to meet the standard and not take into consideration sustainability, holistic approaches, and integration with existing business requirements.
If you are not 100% ready for the audit, you should not be audited. Because an audit is intended strictly to be an independent review of the security program, if your organization does not feel it can meet all aspects of the audit, you should fix it first. Don’t consider your audit a pass/fail game between you and your auditor. That is not the point of being measured, nor is it a best practice. Plus, any audit that is worth something requires a joint attestation by you and your auditor; if you can’t sign off on it, neither should the auditor.
Aim higher than the compliance requirements alone. Information security is one of those areas where going above and beyond the call of duty can be a good thing. Compliance requirements are meant to be the minimum standard by which you are allowed to operate; strive to exceed them. Don’t budget based on just meeting the requirement, but budget based on what you think is required for your organization to manage risk effectively. Yes, that’s risk, not compliance.
As an information security auditor and advisor, I have seen numerous organizations pour budget and resources into a compliance initiative and then literally stop everything after an audit has been conducted. By conveying the importance of building a program based on security that meets compliance, an organization will be better prepared to defend against breaches and satisfy its auditor at the same time.
Subscribe