Archive

Archive for June, 2009

Texting: A Source of Many Security Risks

I was eating at a restaurant a little over a month ago when a couple sitting not too far from me caught my attention. They were hardly touching their food, and they were also completely oblivious to each other. Each was holding a BlackBerry device, completely immersed in texting. I somewhat sarcastically wondered if they would at some time afterwards look back on their meal experience as a special time with each other!

Except for the fact that texters are downright dangerous when they text while they drive, texting isn’t really such a bad thing. But those who do it constantly seem like captives to me. I have heard stories of young couples who have broken up on the grounds that one of them did not reply to text messages quickly enough. Apparently some texters feel snubbed when there is a delay between the time they send a message and the time the recipient replies. I was even told that once one of a romantic duo became jealous because he suspected that the other was texting with a romantic rival of his.

From an information security point of view, however, texting is anything but an innocuous activity. It provides a means to knowingly and unknowingly leak sensitive and valuable information. Heaven only knows how many individuals engaged in by all appearances innocent little texting sessions have revealed proprietary and even classified information. There are some special considerations regarding texting that greatly increase security-related risk:

1. Texting sessions bypass firewalls and other barriers that protect networks. The resulting risks are for the most part ignored, something that is very ironic considering that incoming modem access that bypasses firewalls and peer-to-peer traffic are on just about every organization’s “no-no” list.

2. Texting-related transmissions are seldom if ever encrypted, rendering them extremely susceptible to eavesdropping attacks. The wireless nature of these transmissions makes the would-be eavesdroppers’ task considerably easier. In most cases, therefore, anyone who can capture the information in a texting session can view the entire contents of the session.

3. The content of texting sessions goes through and is usually saved on a server located somewhere. The content of texting sessions is thus out of the control not only of the texters, but also the organization(s) for which they work. If I were ever to decide to make a living by engaging in corporate spying, one of the first things I would try to do is to obtain access to texting servers.

4. Today’s data loss prevention tools, intrusion detection systems, and other security technology currently lack (and may never have) the capability to capture and analyze the content of texting sessions in the workplace. Consequently, if data leakage through texting occurs, it is extremely unlikely that anyone will ever know about it.

Texting and mobile computing go hand-in-hand. Let’s face it—most organizations do little to secure their mobile computing devices and environments in the first place. I would thus not expect a sudden surge of concern regarding the risks surrounding texting. There is at least one time-proven and cost effective measure that organizations can and should use, however—security awareness training. At a minimum, organizations should have mandatory all-hands awareness training sessions that teach users about the dangers of data leakage through texting.

Categories: Uncategorized Tags:

PCI-DSS Compliance: Part 6

OK, OK, this is it in this series, I promise! But I have to say just one more thing concerning the PCI-DSS standard. We all know that many PCI-DSS merchants do as little as they can to be ruled compliant with this standard, complaining all the while. And we also know that companies such as TJX have suffered major data security breaches involving credit card data, yet after agreeing to make major changes in its security controls, instead went back to the way things were done before the breach. In the case of TJX, an internal whistleblower (who was, not surprisingly, was fired) told the world the truth about TJX saying one thing but doing another. But Heartland Payment Systems is a very notable exception. Heartland’s CEO, Robert Carr, woke up to what was really happening there after the massive data security breach, and became determined to do something decisive about the problem. He is not only putting end-to-end encryption in place at Heartland, but is spearheading an effort to create a standard for encryption of data in motion across the entire commercial sector.

Carr’s initiatives are very exemplary, but there is something about this person that from an information security perspective is even better. He is serving as a positive role model among executive management. Let’s face it—way too many executive managers care very little about information security. Assuming that “this could never happen to me,” they view information security as a waste of money. Many of them are extremely resentful of having to comply with the PCI-DSS standard; many are not shy in vocalizing their complaints. Now along comes Carr. He has become a very popular speaker, and in his talks he reportedly sincerely apologizes for what happened at Heartland Payment Systems. He must be extremely convincing, because individuals I know who have heard him speak have told me that at times he appears to almost have tears in his eyes. Then instead of whining about the PCI-DSS standard, Carr has actually gone on record as saying that this standard is too lax and that thus it needs to mandate stronger controls. To put this another way, while other executive managers murmur that it is too costly to comply with the PCI-DSS standard, Carr is saying “it’s not enough—let’s go farther with this standard to the point that it results in a more suitable level of security.”

Hopefully, executive managers around the world will notice and heed what Carr has been saying. Instead of being arrogant or indifferent after Heartland’s data security breach, he is contrite, humble and concerned. Before this breach, Carr thought that such an incident could not occur at his company. Now he knows better. Additionally, information security issues at Heartland have now clearly been raised to the level of executive management.

I attend more than my fair share of conferences and presentations at professional association meetings. I often hear information security managers share something—a success in implementing some new technology, a new way of enforcing compliance with policy and standards, and the like. This is all fine and dandy, and I wouldn’t mind hearing more talks such as these in the future. But conference organizers and others should “mix it up” more by bringing in Robert Carr and others like him. In many ways, they are worth more to information security than the most accomplished of all information security practitioners because as executive management goes, so does an information security practice. So keep it up, Robert—you are truly a star!

Categories: Uncategorized Tags:

PCI-DSS Compliance: Part 5

I was just going to close out this blog series on PCI-DSS compliance when the state of Nevada threw a proverbial monkey wrench into the works. Within the last few days this state passed a law requiring PCI-DSS compliance for all companies that take in credit card payments if they conduct business in Nevada. Additionally, this statue requires that encryption be implemented for all personal and financial data such as driver’s license numbers and bank account numbers used in connection with password entry whenever the information is transmitted outside of a company’s network where the company cannot provide security. The law will become effective on January 1 of next year.

The fact that Nevada is striving to protect its residents from identity theft and other types of computer crime should by now be very clear. For example, a little over a year and a half ago a Nevada statute that required that companies encrypt all personally identifiable information (PII) sent over the Internet. But going as far as to mandate PCI-DSS compliance was a surprise because even though PCI-DSS’s provisions are by no means draconian, they nevertheless tend to cause frustration and resentment among companies and organizations that must comply with them. Given that elections are held periodically and that people vote against politicians who vote for legislation with which they disagree, I am somewhat amazed (but also gratified) the Nevada state legislators went out on a limb to (at least some extent) to pass the legislation.

The new Nevada law is really not as radical as it initially might seem to be, however. Most of the companies there that take in credit card information already must comply with the PCI-DSS standard. Additionally, just as in the case of California’s now classic SB-1386 statute, Nevada’s new law does not prescribe any penalties such as fines for those who do not comply with it. The tougher provisions in this law concern protecting PII, because they to some degree constitute a truly new requirement. The previous law required encryption of any PII sent over the Internet, whereas in essence the new law requires encryption of this information whenever it is sent outside of a network of which a company has control.

I view the passage of Nevada’s new statute as the beginning of things to come. California’s SB-1386 served as model legislation that “caught on” among other states in the US. Presently 41 of the 50 states have some kind of legislation in effect that requires notification in the event of a data security breach involving personal and/or financial data. As I have said so many times before, whether or not legislation that protects consumers or that favors businesses instead depends on which party is in control. Democrats tend to pass consumer-oriented legislation, whereas Republicans tend to eschew such legislation and instead pass business-favorable legislation. Right now the Democrats are in charge, so the door is open for consumer-favorable legislation such as Nevada’s recent law. So watch for other states to quickly follow Nevada’s example.

What may also be significant concerning Nevada’s recent statute is that it takes a standard that was developed and is now widely used in the commercial arena and converts it into law—a very rare and significant event. In a miniscule but yet eye-opening way, it represents what the US government has sought and advocated for years—a partnership between the government and commercial sectors.

Categories: Uncategorized Tags:

PCI-DSS Compliance: Part 4

As I mentioned in my last posting regarding the PCI-DSS standard, PCI-DSS powers-that-be are concerned that merchants may be declared compliant when they have their annual QSA audit, yet they may not be continuously compliant. So I scoured over the PCI-DSS 1.2 requirements and analyzed the time components associated with the various requirements. Here is what I found:

Requirement Frequency
QSA audit Annually
Vulnerability scanning Quarterly
Firewall/router rule set review Biannually
Review of patch installation policies Monthly
Review of application changes Annually
Security review of offsite facility Annually
Inventory of media Annually
Testing for wireless access points Quarterly
Risk assessment Annually
Review of security policy Annually
Employee security awareness and training Annually
Employee acknowledgement of security policy Annually
Incident response plan testing Annually

As you can see, most of the requirements must be met annually. Only one must be met monthly, and two must be met quarterly. Clearly, not much needs to be done all that often. As such, perhaps the fact that so many merchants may not be continuously compliant is easier to understand.

My analysis should by no means be construed as any kind of a criticism. As I have said before, the PCI-DSS standard represents an excellent attempt to provide requirements that reduce the likelihood of merchants experiencing data security breaches involving credit card information while at the same time being reasonable as far as the amount of effort and resources needed for compliance. Note, too, the overall sensibility of the required frequencies. Patching vulnerabilities is something that needs to be done promptly, as the Conficker Worm debacle has so poignantly shown. Accordingly, the PCI-DSS standard requires a review of patch installation policies every month. Similarly, finding and patching vulnerabilities are essential in countering attacks; ostensibly for that reason, the required frequency of vulnerability scanning is quarterly. Rogue wireless access points generally pose severe risk; the PCI-DSS standard mandates a quarterly review of wireless access points.

For the sake of better credit card security, a few time requirements probably need to be made somewhat more stringent, however. For example, a biannual review of firewall/router rules does not seem sufficiently frequent given the criticality of these rules for a merchant’s network security. A rule review every 60 days would thus be better. The same applies to scanning for wireless access points. The speed at which rogue access points can be put in place is frightening. The potential level of risk to not only wireless, but also to nearby wired networks is high. Additionally, scanning for wireless access points is not all that difficult or time-consuming. Requiring scanning for access points every 30 days thus seems more appropriate.

The PCI-DSS standard has evolved over time, and it will continue to evolve as risks and threats change and also as security technology improves. Although most of the time components for PCI-DSS requirements are reasonable, I would not be surprised to see several of them change in forthcoming versions of these requirements.

Categories: Uncategorized Tags:

PCI-DSS Compliance: Part 3

The PCI-DSS standard was created in 2004, and ever since its inception it has been surrounded with a good deal of controversy. Many information security professionals feel that this standard is too lax and needs to be tightened. Many merchants have the opposite opinion; they feel that complying with this standard requires too much money and effort. I have also heard individuals from companies that comprise the Payment Card Industry Security Standards Council (PCI SSC) publicly say that they feel that the PCI-DSS standard represents a reasonable balance between good security and realistic, achievable security. I tend to agree with the last view. Granted, this standard is not ultra rigorous, but it is sufficiently rigorous to ensure that reasonably good practices and controls needed to counter most attacks against credit card data will be in place. The goal of information security, after all, is to mitigate risk to an acceptable, not perfect level. At the same time, if this standard were more rigorous, many merchants would experience considerable difficulty and would incur huge expenses in achieving compliance.

But there is a problem—a big one—with the way PCI-DSS compliance currently works. Once a merchant is certified as being compliant, that merchant is deemed compliant for a year. As Emagined Security’s Chief Operating Officer, Paul Underwood, says, why should an audit be good for one year? He thinks that an audit should be good for as long as the merchant maintain the standards on which the audit was based. Paul’s view is very reasonable, but the question concerning how the merchant and the PCI SSC would be able to know whether or not the merchant remained compliant over time is not an easy one. Several possible solutions include:

• Conduct “mini-audits” over time. The PCI-DSS standard contains twelve requirements. Perhaps every three months or so one or two auditors could randomly choose one or two of these requirements and then perform audits based on these requirements. The merchant would never know in advance what the requirements for upcoming “mini-audits” would be, so the only reasonable strategy would be to ensure that compliance in all required areas be maintained.

• Use a continuous auditing approach. There is a fairly strong movement within the auditor community to collect and analyze audit data on a daily basis, rather than conducting large scope audits every one to three years. Network monitoring could, for example, run continuously; the data could be available to auditors who might look for security problems such as the presence of traffic from an external source that should not have gotten through an edge firewall

I have heard numerous people from the PCI SSC express concern that once a merchant achieves PCI-DSS compliance, that merchant is likely to shift focus to something else besides day-to-day compliance until the next audit is imminent. This, according to these individuals, is what helps significantly contribute to the kinds of data security breaches that WorldPay and TJ Maxx have experienced. Conducting “mini-audits” or using a continuous auditing approach would go a long way in addressing PCI SSC concerns about continuous compliance.

Categories: Uncategorized Tags:

PCI-DSS Compliance: Part 2

In my previous blog entry I discussed the issue concerning merchants that have been certified as being PCI-DSS compliant being decertified after a data security breach. But there is another extremely important issue connected with PCI-DSS certification after a data security breach—whether (or perhaps better said, to what degree) the certifier is liable when a data security breach occurs. Merrick Bank is suing Savvis on the grounds that Savvis was negligent for certifying CardSystems Solutions as being compliant with the PCI-DSS standard less than a year before CardSystems Solutions’ gigantic data security breach occurred in 2005. This bank alleges that USD 16 million in fraudulent transactions have occurred because of this breach. Perpetrators stole information pertaining to 40 million credit card accounts because CardSystems stored credit card information in clear text.

As I stated previously, being compliant with the PCI-DSS standard does not equate to having perfect information security—there is no such thing. Security breaches can and will occur in organizations that have the very best information security practices. At the same time, however, Savvis appears to have badly overlooked the fact that CardSystems was storing credit card data in clear text on its servers. How a competent audit effort could have missed what should have been a critical finding is truly difficult to understand. Of course, the devil could be in the details – it may turn out that Savvis was never given access to review the specific server or informed of the specific server’s existence. Based on the currently available evidence, however, Merrick Bank’s lawsuit appears to have considerable merit.

But what about cases in which a merchant has implemented and conscientiously maintained all the control measures that PCI-DSS mandates, has passed a very thorough and competent PCI-DSS audit, but then a data security breach occurs afterwards? How liable is the Qualified Security Assessor (QSA)? My suspicion is that the Merrick Bank vs. Savvis litigation will open up the proverbial flood gates for lawsuits of this nature. The ruling in this case will also set a powerful precedent for future rulings in cases of this nature. If so, it is easy to anticipate that organizations will start to think twice about becoming QSAs because of the risk of being sued for data security breaches. Whereas organizations have been eager to join the ranks of QSAs, organizations are likely to start to be hesitant about performing PCI-DSS audits. And if PCI-DSS auditors are going to realize more legal risks in connection with future data security breaches, the cost to perform these audits will, unfortunately, most likely skyrocket out of control. If this happens, merchants will not only grumble even more about having to obtain PCI-DSS certification, but will in all likelihood choose the QSA that submits the lowest bid. But you get what you pay for—chances are, the lowest bidder will very often be the least qualified audit service provider, something that will in turn lead to more data security breaches, which will then lead to more lawsuits against QSAs. A vicious cycle of events is thus likely to occur. So stay tuned—many interesting PCI-DSS-related events and rulings are about to happen.

Categories: Uncategorized Tags:

PCI-DSS Compliance: Part 1

The Payment Card Industry Data Security Standard (PCI-DSS) is a global information security standard that the Payment Card Industry Security Standards Council (PCI SSC) created to help thwart credit card fraud by requiring organizations that collect, process and store credit card data to deploy appropriate security measures. Of all the information security regulations that exist today, the PCI-DSS is on more organizations’ proverbial radar than any other compliance standard. This is not to say that HIPAA, SoX, Gramm-Leach-Bliley, NERC, and other standards are not important. It’s just that wherever credit card transactions occur, and they occur just about everywhere, PCI-DSS applies. This means that even institutions such as universities with long-established reputations for being lax when it comes to information security, are now being held to the same data security standards as are merchants that do the same volume of credit card processing. At the same time, the effort and resources needed to achieve PCI-DSS compliance depend on the amount of credit cards transactions. Level 1 (high credit card volume) merchants are held to considerably higher compliance standards than are level 4 merchants (see www.visa.ca/en/merchant/fraudprevention/ais/merchlevels.cfm). Level 1 merchants must achieve compliance by having and passing an annual independent assessment of the security of credit card data perfomed by a Qualified Security Assessor (QSA). Merchants that have considerably smaller volumes of credit card processing need only complete a Self Assessment Questionnaire (SAQ)

How compliance must be achieved depends on the volume of credit card transactions. Organizations that handle large volumes of transactions must have their compliance annually assessed by an independent assessor termed a “Qualified Security Assessor” (QSA), whereas companies that handle much smaller volumes have the option of self-certification via a Self-Assessment Questionnaire (SAQ).

One would think that once a Level 1 merchant passed a QSA audit, the merchant’s compliance status would be good for one full year. Although this is normally true, glaring exceptions, one with WorldPay and another with Heartland Payment Systems, have recently surfaced. In both cases, the PCI-DSS powers-that-be declared these companies to be non-compliant after they experienced massive data security breaches. These powers-that-be have made outstanding decisions over the years, but revoking a merchant’s compliance status as the result of a data security breach is a pill that is a bit tough to swallow. WorldPay and Heartland Payment Systems ostensibly had good security in place at the time of their data security breaches. (The good news is that Heartland Payment Systems was declared compliant once again only a few weeks after it was ruled not compliant.)

 

There is no such thing as perfect security. As good as it is, the PCI-DSS standard does not require anything close to perfect data security, nor is any audit, even an audit performed by the most qualified QSA, anywhere near 100 percent comprehensive. Residual risk will always be present as long as computing systems are turned on, and this risk only escalates if they are connected to a network. Therefore, experiencing a data security breach should not in and of itself be the reason for revoking any merchant’s PCI-DSS compliance status.

 

Categories: Uncategorized Tags:

The New Intrusion Detection: Part 2

How must intrusion detection change to enable it to keep up with the ever nastier and subtler attacks that have been occurring over the last few years? There are several possible answers to this question, but in my mind a common denominator in today’s security breaches is the presence of malware. At a minimum, attackers want back doors on systems that they have compromised, but why have just a back door when you can make the owned system part of a botnet that can generate spam to bring in some cash? Or why not rent out the botnet to a perpetrator who is less technically sophisticated? Malware can also be used to infect systems, something that helps keep perpetrators nearly totally out of the spotlight. Read more…

Categories: Uncategorized Tags: