Many years ago, I consulted with a non-profit agency that needed firewall remediation. They had just purchased an upgrade to the vendor’s latest and greatest firewall, and needed to build a policy that met their needs. One of these was the need to control the use of instant-messaging throughout the environment. Indeed, the Security Director was obsessed with stamping it out completely. Instant-messaging clients were notorious for finding egress paths out of the environment, and could find an open port in the firewall. Therefore, it stood to reason that all unused ports would be plugged, sources requesting to use these ports would be checked against the policy, traffic would be thoroughly inspected, and known destinations hosting instant-messaging servers would be blocked. This resulted in no less than 39 firewall rules dedicated just to blocking all instant-messaging traffic that could possibly exist.
In many ways this “war” against instant-messaging clients was a success - the traffic was locked down airtight. But much time had been expended in an exhaustive effort to find every possible source and path of this traffic, as well as in designing, implementing and testing the effectiveness of the controls to stop it. No doubt another vendor would have come along with a product that could handle it in ways that no firewall ever could - just plug it in, send the traffic our way, and we handle the rest?
From a much broader perspective, we spend time fighting to reduce risk - increasing the effectiveness of security controls - this is our role as the Information Security professionals. We understand that a security control that is 90% effective is better than a control that is 80% effective. But we also understand that there is a cost differential between the two - and 90% is probably not good enough. What will it take to get to 100% (e.g., stamp out all instant-messaging traffic) - and can we afford it?
Rather than expending much effort and expense to get to 100% effectiveness, we can combine multiple layers of security, each layer significantly less than 100% effective, but with the right combination we can approach 100% effectiveness through synergy between the controls.
Let us suppose we have a security control that is 80% effective at protecting our resource. Perhaps this is an Administrative control - a policy or procedure that controls personnel behavior. In this example, this particular control alone is 80% effective.
A clear target for improvement - replacing this control with another that is closer to 100% effective. But again, how close to 100% can we come and how costly is this stronger control?
Another option is to add a second control to bolster the first control, perhaps a Technical control that controls logical access at the network layer. Let us assume this control is also 80% effective. If the first control eliminated 80% of risk, and the second control eliminates 80% of the remaining 20% not addressed by the first control, we have now increased our effectiveness to 96%.
Effectiveness may be calculated as:
E total = 1 - ((1-E1)*(1-E2)*(1-E3)…)
Where E total is the total effectiveness of the security controls, and En is the effectiveness of any one control in the system.
So in this case, the effectiveness is:
E total = 1 - (1-80%) * (1-80%) = 96%
In other words, by combining two security controls whose effectiveness is each 80%, we have built a solution that is 96% effective.
Let us take this a step further and add another 80% effective control: this time at the system-level:
E total = 1 - (1-80%) * (1-80%) * (1-80%)= 99.2%
At this point, we have increased our effectiveness to over 99% by combining three controls whose individual effectiveness is 80%. We could stop here, but for the purposes of this exercise, we will add another control. Imagine adding an application layer control:
E total = 1 - ((1-80%)*(1-80%)*(1-80%)*(1-80%)) = 99.84%
If we continued to be obsessive about reaching 100% effectiveness, and the cost wasn’t prohibitive, we might include a fifth security control, this time a Physical control:
E total = 1 - ((1-80%)*(1-80%)*(1-80%)*(1-80%)*(1-80%)) = 99.97%
What we conclude from this exercise is that individual security controls do not need a high rate of effectiveness to be part of an overall security system that is effective by leveraging synergies of adjacent controls. We also note that as each additional control is added, security effectiveness improves, but at a declining rate: Adding a second control increased our effectiveness by 16% — adding a third control increased effectiveness barely more than 3%, and by the time we discussed adding a fifth control it yielded an increase of 1.3% effectiveness.
As with all security controls, we must first understand not only the level of risk facing an asset, but must also understand the level of risk that is acceptable. Our goal is not to eliminate all risk completely, but to reduce level of risk to an acceptable level. The selection of security controls must be appropriate to meet or exceed that level risk reduction through adequate control effectiveness. When we find that we encounter diminishing returns in increase of security effectiveness, it is time to consider concentrating our efforts in other areas where security improvement is needed - and where we may realize greater return.
Let us turn to “Social Engineering” for a moment. The first thought for many of us is the writings of Kevin Mitnick (The Art of Deception and The Art of Intrusion, co-authored with William L. Simon) that used real-life and hypothetical stories to demonstrate how social engineering can be combined with hacking to bypass technical security controls. We think of the call to the help desk in the middle of the night to unlock the executive account, and the psychological pressure exerted by the attacker implying retribution if the task is not carried out immediately. Or perhaps a rogue website that is accessed through a series of phishing emails that in turn collect sensitive information.
But what about an attack on a security system that affects the availability of the action of the security controls and/or the availability of the resource that the control is intended to protect? Compromise of data then simply becomes a waiting game for the would-be attacker. This “un-social” engineering attack may include little or no interaction between the attacker and the target. Let us dub it “pressure engineering” or a subset of social engineering.
Imagine a Mr. Mugglesworth working under a tight deadline. At the completion of the work, it must be submitted, transmitted and/or stored in a secure manner. Mugglesworth is as good about following the security procedures as he is about getting his work done on time. Indeed, Mugglesworth is trusted with some of the most sensitive information in the company. But when he tries to submit his work, something is wrong. The security control is not allowing him to proceed. Or the system is not able to accept the work in a secure format. The pressure mounts as the deadline approaches. Mugglesworth is counted upon to complete his work on time, and a missed deadline with “security” as an excuse simply will not do. The temptation to bypass the normal security procedures in order to complete the task is great - especially since the technical or managerial resources are not responsive. (It is after-hours and no one is available to assist.) When the right personnel are available to assist, the deadline will have long passed.
Will Mugglesworth or his superior make an “executive decision” to handle the sensitive information in an insecure manner? Or will they wait it out? The pressure mounts… pressure engineering has been applied.
The answer to this question will depend on the security culture at Mugglesworth’s organization. It may depend on the type of security training and the expected employee response that is cultivated. It may also depend on how the technical issue is escalated and the organizational response.
Where do “Da Rules” fit in at your organization? What would Mr. Mugglesworth do if he worked for you? How would you and your organization address this scenario?
A dichotomy exists between information and data - and the way that information and data are discussed, stored, protected, and used. Any number of people reading this might identify themselves as working with “Information Systems” in the field of “Information Technology,” and some of them work with “Information Security.” Sometimes they attend meetings and talk about “Information” and “Information Sharing.” But most often they are talking about “data” - data flows, data stores, data shares, data systems, data access, data security, and so on.
There is no need for a primer on the difference between data and information. It is clear to the users of information that what they want is information. They may ask for data, they may seek so-called data points, but what they are really asking for is information. After all, information is useful; it makes the difference between decisions and informed decisions. And at the end of the day, the information systems people deliver information to decision makers. They store this information in their information bases. No, wait a minute - it is stored in databases. So what they are really working with is data?
Data becomes information when it delivers something meaningful to someone. We can take any block of data and extract from it an endless stream of meaningless information. An example is baseball. From data recorded from each game, we can extract the number of runs scored, the number of bases stolen, the number of games won at home, the number of games won away, the number of errors made in the last ten years… the list goes on to infinity. Who cares? Well someone at some point may care. Perhaps the real question is “Which was the best team last season?” Or perhaps “Who is the best player of all time?” Or any other question you could dream up. Regardless of the question, the fact remains that the person recording the plays and the scores at each game does not seek to answer these questions. He/she is simply collecting data and storing it for later use. What will it be used for - 50 years from now? Who knows? Who cares? For some just simply knowing that the players will be back on that field next season is good enough. In the meantime, just let our information people hold on to that data in a safe place so that it’s there when we need it, for whatever reason we might need it .
Now let’s say that some of that data is sensitive. Well, we should protect the sensitive data. Which data is sensitive? (I don’t know - it’s your database, you tell me) The sensitivity of the data will be determined by the sensitivity of the information that will be conveyed when it is accessed. Meanwhile, are you keeping your eye on the ball like a good player? Good - I just stole second base. Are you keeping your eye on second base like a good fan? Good - I just stole your hot dog from under your nose.
Regulation guides us to identify what data is sensitive. PCI DSS tells us to protect cardholder data. HIPAA directs us to protect health and medical information. Upper management decided that your customer list is private and must be protected from the competition. Everything else is not sensitive and need not be protected the same way.
Yet I know of a web-based charity that boasted of impenetrable cardholder data security. Indeed it was. But when credit card accounts were stolen from donors who made charitable contributions to the organization’s website, it was the customer contact list that was stolen, not the credit card database. Why go through all the trouble of hacking a secure database when you can simply telephone the donor and ask for it? They were just as willing to give it out over the phone as they were online.
Information is pulled from an information system. When we know WHAT information will be pulled, and when we know HOW that information is sensitive, then we know the sensitivity of the data from which that information came. If we don’t know the sensitivity of the information or how it might be used, then we don’t know the data. Since it is the job of information systems professionals to store all data holistically, then it is their job of securing all data holistically - not selectively.
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.
Here we continue our discussion of “what happens when a Merchant outsources their e-commerce environment.” In Part I, we touched on the types of e-commerce operators, including those that are purely e-tailers and those that are mixed brick-and-mortar and online retailers. We began a discussion about scoping the e-commerce environment for PCI, what is clearly in scope and what is clearly out of scope. Now we will examine what is NOT clearly in or out of scope, as well as the implications of different combinations of in-house and hosted environments, and their implications on PCI scope.
But first, let’s review from last time our basic scoping argument for a typically e-commerce environment:
We are all familiar with the large e-tailer environment – the ones with the popular web pages that have categories upon categories of items for sales, shopping carts and secure transaction pages for placing orders. We also touched on the retail sites that allow you to purchase gift cards, or to order merchandise or to pre-order items for in-store fulfillment. Clearly, these are also e-commerce operations. In all of these cases, a website at some point completes a purchase by collecting cardholder data from a buyer and then enters order information into some type of an order fulfillment or an order management system. This much is clear. What is also clear is what most often is NOT an e-commerce site: Any site that does not prompt for payment, and doesn’t allow you to purchase anything. There may be catalog items, and pricing information, even product availability information that lets you look up store stock in real-time – but the site never handles any cardholder data. Lots of content and pretty pictures, perhaps flashy videos, but no cardholder data. No, not within scope of PCI.
But what about the web site that has a combination of both? It has all of the flash, the ads, the interactive product guides and also allows for you to purchase items – right from your browser. Definitely an e-commerce site and definitely in scope for PCI? Right?
Once again, the answer is “It depends” and “It varies.”
Let’s take a step back and see what happens on that xyzinc.com website: we start on a “landing” or “splash” page, use certain navigational elements to make our way through the site, and eventually end up with a shopping cart and/or a screen to complete an online purchase. Despite our web-surfing perception that all sites look and act basically the same way, the variability of web site architecture belies what our browser displays to us.
In one scenario, all of the content may be hosted on a single web server (or cluster of web servers with server persistence) environment. Clearly, the server and the applications running on it are within scope for PCI.
In another scenario, the server acting as an agent to complete the online transaction is physically hosted on a different machine, and might even lie in a completely separate network, segmented from the environment that hosts the content web server that brought you here in the first place. Thus the browser experience is seamless – you looked at products and flashy ads on one server, and when you were ready to buy you were handed off to another server that handles the cardholder data and communicates through middleware to a database back end - and the payment processing environment. If the Merchant organization segmenting things adequately, the PCI assessor would rule the first batch of web servers out of PCI scope, and the second batch within scope – as the former does not handle any cardholder data and the latter surely are within the path of cardholder data flow.
OK, now we seem to be getting somewhere. But exactly where? Yes, the question is “where” – where are these machines hosted? Where do they live?
It is entirely possible that the payment processing applications reside in a hosted environment that does not belong to the merchant that owns the website. Thus, the merchant can claim that they e-commerce environment is out off scope. Once again – it depends and it varies. The key to understanding the scope is to understand the flow of cardholder data. What happens to the cardholder data after it is accepted by the e-commerce server?
As a QSA, I have seen cases where the transaction data is sent back to the merchant’s mainframe environment and processed just like any other in-store retail purchase. I have seen others where cardholder data is sent directly from the hosting environment to the payment processor/gateway for authorization. At one retailer, I had witnessed two extreme examples of this – one e-commerce environment that was hosted by a third-party but owned, maintained and developed in-house by the merchant – and a second e-commerce environment that was hosted and managed by yet another third-party provider, as a turn-key solution offered on a “soup to nuts” basis.
Here was a case where both of the retailer’s sites were hosted by a third-party, with one out of scope and one definitely in-scope for their PCI assessment.
Clearly then, hosting of an e-commerce environment by a third-party does not automatically equate to “out of scope” for the retailer. As a matter of fact, the litmus test for scope greatly depends on who operates the website – if it is completely external to the retailer’s environment, if it is developed, maintained and operated by the third-party, and is hosted on equipment that is not owned by the retailer, then the environment is most likely out of scope for the retailer’s PCI assessment. If the site is hosted off-site, but the equipment belongs to the retailer, its web payment applications are developed/maintained by the retailer’s development staff, and the servers it runs on are in fact managed and patched by the retailer’s IT staff, then the site is most likely 100% in scope for PCI.
Some interesting variations: Site is hosted by a third-party, equipment is owned and managed by the same third-party, cardholder data transactions flow directly to the Acquiring Bank’s gateway – and the applications are developed in-house by the retailer (e-commerce environment is largely out of scope, but some elements of this ARE in scope – particularly the e-commerce development processes); Code is maintained by the third-party, a “web hosting” company and the servers are also hosted at the same facility – but the servers are owned by the retailer and the OS is patched and maintained by the retailer remotely (applications most likely out of scope, as is the development environment – but the hardware is in scope for PCI along with the remote access methods and IT administrative procedures. And likely so is the entire e-commerce environment – but not necessarily).
The preceding accounts for some gray shade areas that the QSA must wrestle with when determining the scope for a mixed-responsibility e-commerce environment. As a rule of thumb, the best approach is to consider an e-commerce environment in scope, then determine which pieces of it are outside the scope. As different pieces of the environment are excluded from scope, the blurred boundaries of responsibility begin to sharpen and soon the areas that lie within scope become apparent, as do the areas that can remain excluded from scope. In the end, the scoping section of the Executive Summary of the resulting ROC will read to the effect “In scope: The e-commerce environment, with the exception of the following: <…>” If all areas of the e-commerce environment can be excluded from PCI scope, then a valid argument can be made that the e-commerce environment is out of scope for the assessment. If not, then the exercise results in a narrowing of scope for the e-commerce environment and the fulfillment of our ultimate goal.
Subscribe