Securitization: A Risk to Compliance Integrity

This morning’s paper had yet another story about a major security breach at a payment card processor. In “Credit Card Processor Says Some Data Was Stolen”[1], the compromise of a large number of credit card numbers and other data was recently reported. Presumably this processor was reviewed under the applicable standards, so why are data breaches continuing?

Data breaches are inevitable. Standards do not prevent breaches; they merely impose a minimum level of protective measures.

However, it is always fair to ask: “Are our standards protecting us as well as they can?”

IT professionals are experienced at dealing with complex rule-based systems. If there is a problem with a program, problems may lie in

Corrections are always possible; if the correction is not straightforward, at least the problem and the underlying reasoning can be exposed and understood. The compliance universe is often not so precise.

IT compliance often has a fundamental flaw: Different aspects of the process are parceled out to different groups. Relationships between different groups are governed by a contract. In an imperfect world, shortcomings in checklists or procedures can create an impenetrable morass, requiring mindless conformance to non-applicable requirements. At its worst, the combination of shortcomings can create cascading failures, where no one has the power to correct the problem.

This phenomenon is also fundamental to other less formal systems: unforeseen circumstances are one of the reasons for the present turmoil in the financial industry.

The ongoing crisis in the financial markets has made visible the previously arcane world of debt securitization. At the heart of the crisis is a relatively simple reality: No longer is a loan a two-party transaction between borrower and lender. The initial loan transaction is now the opening step in a process which will parcel out pieces and aspects of the debt to different parties. A series of agreements governs the relationships between the different parties, but not all the agreements are visible to all parties. Worse, the inflexible terms of the isolated agreements may force a party may to act contrary the interests of the whole. When everything goes according to plan, things work well. The situation can become chaotic when events fail to unfold as planned.

The segmentation of compliance has created a similar environment. Compliance with foreseen conditions works; unforeseen circumstances present a challenge. Often there are no provisions for feedback when an underlying problem is revealed. When a mandatory compliance checklist has an incorrectly codified rule or a deficient certification procedure, this problem is highlighted. If mandatory requirements do not take into account all factors, there is presently no mechanism to allow for revision of the requirements.

This kind of frustrating bind is common. For example, I am sometimes required to provide a signed letter from my employer authorizing me to participate in an activity. Invariably, when I point out that I am the owner (and thus my own employer), I am told that the letter is still mandatory. In the end, I write and sign a letter authorizing my own participation in the activity, thus allowing someone to check off the item on the checklist even though the item does not mean anything in that situation.

Recently, the United States Internal Revenue Service gave my tax attorney a similar experience. The Internal Revenue Service had deemed a taxpayer’s Employer Identification Number inactive for one reason: the non-filing of a Form 941 over a period of years (Form 941 is used by employers to report taxes withheld from payroll). The Service’s internal procedures had not identified the possibility that a small business could be active and not have a payroll. As a result the number was purged from their system.

To their credit, I am told that the Internal Revenue Service has agreed to reinstate the EIN, after the taxpayer supplied documentation that the number had been used continuously in other required ways. However, it is extremely unlikely that there is any way to determine if the processing procedures have been updated to correct this analytical oversight. The long-term solution to that client’s problem is likely to emulate an experience cited over 30 years ago in “Behold the Computer Revolution”:[2] file a quarterly Form 941 reporting $ 0.00 wages and $ 0.00 taxes withheld, thus indulging the computer.

Recently, I had personal experience with the compliance review required by the PCI Security Standards Council under their PCI Data Security Standard.

Our practice is not a typical retail business. Most of our clients are themselves businesses, mostly corporations. Most accounts are paid traditionally, with checks, Automated Clearing House (ACH) transactions, and wire transfers. We have seen perhaps $ 50.00 of cash in three decades. Unlike a retail store, payment cards (e.g., MasterCard, VISA, American Express, Diners Club, and Discover) do not represent the majority of our sales. Clients often make use of cards to expedite services in time-critical cases where the normal purchasing mechanisms are not usable. We process our transactions using an online service accessed through a Web browser interface. The connection to our processor is an SSL-based, high-grade (128 bit) encrypted connection. There are no copies of credit card information stored anywhere but on paper in a filing cabinet, in a locked office.

All merchants accepting payment cards are now required to comply with the PCI standards. Our processor, as provided by the standard, retained one of the major authorized vendors to verify our compliance. Since credit card information only transited our Internet connection highly encrypted, and our processor indeed encourages us to process our transactions from anywhere, compliance should have been no more difficult than someone with a Web store operated by a major provider.

As Alice discovered, life down the rabbit hole is not always as simple as it seems.

I was informed that since we had an Internet connection, full compliance with the scanning requirements was required. We were required to verify the security of each and every Internet-accessible asset, whether or not the asset is in any way included in the processing of PCI data. The fact that the connections are solely used to transmit encrypted data is irrelevant.

Since we have an Internet connection, and transaction bits go through our network in any form, even fully encrypted, compliance with all of the PCI scanning requirements is obligatory. Indeed, there is a specific requirement that the Scanning Vendor’s IP address be exempted from the Intrusion Detection System (IDS) and Intrusion Prevention System (IPS).[3]

It did not matter that the only system used that actually processes PCI-related data was a mobile computer that was powered off. The fact that the data is fully enciphered from the point that it leaves the Web browser through the entire journey to our processor was of no consequence.

Our configuration is typical for a modest network, in that the vast majority of connections are proxied by a firewall/router. The side effect of this is that all connections seem to originate or are received by a single address, as does our Website and our email connections. That the external address actually mapped to a number of different machines was also considered of no consequence.

For a long time, I thought that this was related to the Approved Scanning Vendor’s interpretation of the PCI procedures. After weeks of asking for actual citations to authorities, I was finally given citations to two documents, the PCI Security Scanning Procedures[4] and the PCI Security Audit Procedures.[5] These documents specifically identified some of the most unproductive requirements as mandatory.

This is not to say that PCI compliance is futile or useless. The problem of maintaining integrity of PCI processing systems is real, as is the problem of compromised PCI data, a point I strongly noted in Chapter 30 of the upcoming 5th Edition of the Computer Security Handbook. This is abundantly clear from the most recent case, as from the past well-documented cases at TJMaxx, Marshalls, HomeGoods, Hannafords, and others.

For many if not most situations, the requirements are appropriate. The shortcomings become apparent when a configuration is different from that envisioned by the authors of the standards and checklists. The lack of effective feedback and redress when a deficiency is encountered magnifies the inappropriateness.

Specifications do not exist in a vacuum. They are the creation of one or more minds, with a viewpoint on the problem. When I architect systems, I try to be careful to maintain flexibility. My architectures and designs do have a viewpoint, but that I try hard to keep the viewpoint to the “what” and not the “how.”

This is not a phenomenon limited to the IT-community. In other areas, standards also impose questionable requirements in the name of safety. The pre-washed salad greens market may be yet another example of this phenomenon. After an incident involving E. Coli 0157:H7 contamination which forced a large recall of baby spinach, the major producers instituted the California Leafy Green Product Handler Marketing Agreement. The announced goal of this agreement was to ensure that such an incident did not recur. However, as recounted in “ Politics of the Plate: Greens of Wrath” (Gourmet, November 2008) the standards may have undesirable side effects. According to this article, producers of organic salad greens are effectively required to use destructive measures in areas bordering their fields in the name of eliminating unproven sources of possible E. Coli 0157:H7 contamination.

Voice-over-IP (VoIP) technology is another area where one can conceive of an Internet compliance question. In particular, how does one correctly comply with scanning requirements in the context of a VoIP appliance? If a stand-alone authorizer is connected to a telephone line and the telephone line happens to connect to the carrier or central switchboard using VoIP technology, is there a problem? Obviously, such an installation has an externally visible IP address. Should all such sites be deemed to be “processing transactions over the Internet”? What about those sites where the use of VoIP technology is not known to the department responsible for compliance?

These questions are not idle. Many small and medium businesses (SMB) use VoIP through their local cable carrier.

What question is missing from the PCI compliance regime? At the most basic level, the erroneous presumption is that if PCI data transits a network, the network must be scanned. This perspective gives the appearance of security without actually providing security. What about the network outside of my office, the one managed by my ISP? Must they be scanned? What about all of the Web and other servers on their network?

There is a different aspect as well. These presumptions have even more serious implications. They relate to whether Secure Sockets Layer (SSL)/Transport Level Security (TLS) and the mobile computer can be trusted. The laptop was not scanned, and in any event was behind a firewall proxy server, which deflected all incoming requests; thus, it is more trustworthy than the system(s) scanned by the compliance review, but this aspect of the system was deemed irrelevant. Similarly, “white-listing” the authorized scanning vendor’s IP address creates a trust vulnerability.

If SSL/TLS to a site using a financial-grade, publicly-registered X.509 certificate is unsecure, the implications are far more serious. The repercussions extend far beyond the payment card industry: all financial transactions are at risk, and the entire industry should stop using SSL/TLS.

While there are potential problems with SSL, these problems do not appear to be the issue. What is far more likely is that the possibility of processing payment cards over a HTTPS (HTTP over SSL) connection that then travels over an otherwise untrusted network was not considered when the checklists were written.

It should also be noted, that while the PCI procedures specify the use of encrypted links, there does not appear to be a requirement that the X.509 certificates used to establish authenticity and encryption actually be issued by a well-recognized Certification Authority.

Coming full circle, the hazard of securitization is that when arrangements are cast in stone, without provisions for constructive feedback when conditions change, the side effects are unpredictable, both in security and risk.

Postscript

An abridged version of this essay appeared as a guest column in NetworkWorldFusion under the title “Is compliance with standards achieving the goal of protecting data?” on February 9, 2009.

Notes

[1] Dash and Stone, “Credit Card Processor Says Some Data Was Stolen”, The New York Times, January 21, 2009, pp B4
[2] “Behold the Computer Revolution”, pp 593
[3] PCI Security Scanning Procedures, pp 4
[4] Ibid
[5] PCI Security Audit Procedures (under “Wireless”, page 6; DSS Requirements 2.1.1, page 13, et seq. and 4.1.1, page 22)

References

Picture of Robert Gezelter, CDP
RSS Feed Icon RSS Feed Icon
Add to Technorati Favorites
Follow us on Twitter
Share
Bringing Details into Focus, Focused Innovation, Focused Solutions
Robert Gezelter Software Consultant Logo
http://www.rlgsc.com
+1 (718) 463 1079