Research

As part of our Debix contest (which is open for a few more days, if you want to enter) one reader relayed a great story on how he was scammed on eBay, and fought back. With a little ingenious detective work, he… well, I’ll just let Jay tell his own story (split into two parts)… Back in 2001 I worked in a small ISP, it was so small that I represented half of the staff. I had offered to help a friend and his wife buy a laptop. Money was tight for them, so after doing some comparison shopping we decided to snipe a laptop off of EBay. Shortly after winning an auction on a good laptop, the seller sent an email with a story about his brother having financial problems. It was written inconsistently and I couldn’t tell if this guy was lying or just a bad writer. The seller asked that I send a cashiers check to his brother in Indiana. I had gotten a great price on the laptop for my friend, so greed won out over logic but my warning lights were flashing. After a few more emails I sent the check and communication stopped. I waited for a few silent days before I went back to EBay. It turns out EBay had (and has) this great service where you can look up the account information of a seller. EBay provided the name and address of a person living just outside of Washington D.C. With the help of a reverse lookup, that led to a phone number which brought me to my first of many interesting phone calls. I reached the seller, who we’ll call John, on the phone. After an awkward opening, I learned that John had been battling identify theft and had nothing to do with the EBay listing. He’s had fraudulent credit card charges from online purchases. He was just as interested in finding these folks as I was… I was stuck before I began. I had two leads, the email address and the address in Indiana where I sent the check. I used Google maps to find the Indiana address. From the aerial photography I learned the address was at a large apartment complex. I called the local police in Indiana, “EBay?” “Yes, an online auction site.” “…On the internet?” They told me that they couldn’t help me since I was in Minneapolis and that I had to contact my local police department. I tried to get them to drive by the address and check out the mail boxes. They wouldn’t budge. My local police were a little more well versed, “Yeah, Haha, EBay again”. They told me that since I mailed the check to Indiana the crime really happened in Indiana and there wasn’t anything they could do. After a few rounds I was told I could show up at my local police to fill out a report but that they wouldn’t do anything but file it. At this point I figured I could call the FBI because they’d have to help. I assumed since it was across state lines and it was a crime on the internet it must be against all sorts of laws I didn’t know about. Plus I’d been to DEFCON, I knew the feds were out there and watching. Turns out I was a little off about the feds. Once I found someone willing to talk about the case, I learned that fraud for the price a laptop was a little below the FBI radar by, oh, a 1000 percent or so. Come back tomorrow, when Jay will share his efforts to track down the culprit… < p style=”text-align:right;font-size:10px;”>Technorati Tags: Fraud Share:

The conference season is upon us. This week we discuss SOURCE in Boston and RSA with our guest, Jennifer Leggio. We spend a bit of time on the Hannaford breach and my Mac antivirus article. As always, full show notes and the podcast are here. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Network Security Podcast Share:

Make the list of who is compliant (and by default, not compliant) public. Allow consumers to decide if they want value security enough to do something about it. < p style=”text-align:right;font-size:10px;”>Technorati Tags: PCI Share:

Update : Yes, I know it’s the QSAs not ASVs that certify. Dumb mistake on my part. Yesterday I posted an analysis of the Hannaford breach in which I made a contentious statement. In other words, PCI is worthless. Some of the commenters weren’t too pleased with this statement, an example from @Mike: That said, to discount the program as “worthless” makes me question how informed the person saying it really is about this topic. I’ve been digging into PCI since before it was PCI (Visa CISP) and talked with all sides, from struggling retailers, to credit card processors, to auditors, to the big guys themselves. You might not like my conclusions. You might think I’m an idiot. But I’m definitely a well informed idiot. Now back to PCI. I admit that PCI isn’t completely worthless. But let’s not call something that’s degraded into a very costly awareness nudge an effective industry standard for protecting cardholder information. Pretty much everyone involved, with whom I have discussed PCI, admits it’s not very effective- especially considering the cost. A few points and suggestions for fixing the system: PCI-DSS was established to transfer risk from the credit card companies to the retailers and processors. There is a lot the credit card companies could do to reduce risk on the processing side, but they have instead chosen to push it onto the retailers and processors. Going back to CardSystems, a large majority of major breaches involve companies that were PCI compliant, including (probably) Hannaford. TJX is an open question. In many cases, the companies involved were certified but found to be non-compliant after the breach, which indicates a severe breakdown in the certification process No ASV has been dropped from PCI, even after certifying non-compliant companies. There is no accountability in the system. ASVs are allowed to offer services to the companies they certify, which is a built-in conflict of interest. They should be held to the same standard as financial auditors where the audit function and compliance assistance/services/consulting cannot come from the same auditor. Many auditors certify compensating controls that are clearly ineffective. Due to lack of accountability in the system, companies push ASVs for the lowest price possible to achieve “compliance”. This price pressure leads to cheap certification, and the approval of inadequate controls mentioned in point 5. PCI-DSS is moving to a checkbox that doesn’t necessarily reflect any level of security, and the credit card companies are okay with that since they can just later find the company in violation after a breach, yank certification, levy fines, and push all costs to the retailer. We can fix PCI, but right now it’s very ineffective at stopping real breaches. The standard needs to adapt faster; there needs to be accountability and separation of duties at the auditor level; and the credit card companies need to adjust the processing system to reduce fraud- not just set an incomplete standard for retailers. Maybe not worthless, but considering the cost we sure as heck should be getting more out of it. Some companies use PCI to improve their security, but many others do as little as possible to comply, and thus security isn’t increased in any meaningful way. < p style=”text-align:right;font-size:10px;”>Technorati Tags: PCI Share:

There goes another one. According to multiple sources, the Hannaford Brothers grocery chain suffered a major breach with 4.2 million credit cards exposed. Hannaford had published an FAQ for their customers. Odds are it will be months until we find out what really happened, but I’m going to speculate anyway, pick apart the press coverage and FAQ, and see if we can learn something from this now. As usual, the information released is incomplete and contradictory. PORTLAND, Maine (AP) – A security breach at an East Coast supermarket chain exposed 4.2 million credit and debit card numbers and led to 1,800 cases of fraud, the Hannaford Bros. grocery chain announced Monday. Hannaford said credit and debit card numbers were stolen during the card authorization process and about 4.2 million unique account numbers were exposed. The breach affected all of its 165 stores in the Northeast, 106 Sweetbay stores in Florida and a smaller number of independent groceries that sell Hannaford products. This is interesting since there is a direct tie to fraud, as opposed to many other breaches. This often means the fraud was detected in the credit system and then traced back to the retailer, which seems to be what happened based on the FAQ. As a researcher it’s always helpful to be able to tie the breach to illegal activity. This does, of course, suck for the victims, but as long as it’s credit card fraud they are protected. Since the information was stolen during the authorization process, and was distributed over many locations, it means a compromise of the central authorizations system or the credit card processor. It could be as simple as sniffing unencrypted communications, or a more complex compromise of a database or application. My money is 70% on sniffing, 30% on something in the database. No personal data such as names, addresses or telephone numbers were divulged – just account numbers. This can’t be true. Without names, the card numbers are unusable. Hannaford became aware of the breach Feb. 27. Investigators later discovered that the data breach began on Dec. 7; it wasn’t contained until March 10, said Carol Eleazer, Hannaford’s vice president of marketing in Scarborough. “We have taken aggressive steps to augment our network security capabilities,” Hannaford president and CEO Ronald C. Hodge said in a statement released Monday. “Hannaford doesn’t collect, know or keep any personally identifiable customer information from transactions.” This reinforces the likelihood of a network breach and sniffing, assuming the statement is true. How was the network breached? Could be any one of hundreds of ways. Targeted phishing and compromise of the central network from a remote location are common. I can’t add anything more than pure speculation on this one. The company urged its customers to monitor their credit and debit cards for unusual transactions and report any problems to authorities. Actually, card issuers should reissue the cards and just eliminate the chance of greater fraud. This is irresponsible. Since this is just loss of credit cards, there is no need for identity theft protection. Mark Walker, an attorney for the Maine Bankers Association, said his organization sent an advisory to member banks Friday after learning of the breach. Only a few had reported suspicious activity involving the credit and debit cards they had issued customers, Walker said. “I had expected there would be more than we’ve heard of,” Walker said. “But it’s still too early for us to tell.” Strange- I consider 1,800 to be a large number. It could be that the fraud was performed directly in the Hannaford system or something. Or this is an erroneous statement. The FAQ gives us a little more information and narrows things down. What happened? Hannaford announced containment of a data intrusion into its computer network that resulted in the theft of customer credit and debit card numbers. This data was illegally accessed from Hannaford”s computer systems during the card verification transmission process in transactions. Further, Hannaford is cooperating with credit and debit card issuers to ensure those customers who may be affected by the theft are protected Somewhat contradictory, with a mention of data security and network, but I don’t expect everyone to be as picky about those details as we are. I suspect the last sentence means fraud alerts are in place, and cards are probably being reissued to some extent. When did you discover the intrusion? Hannaford was first made aware of suspicious credit card activity on Feb. 27, and immediately initiated a comprehensive investigation with the assistance of leading computer security experts Bingo. It was detected by the banks or credit card companies, then brought to Hannaford. Is it safe to continue shopping in your stores? We have continually devoted significant round-the-clock resources to ensure Hannaford has comprehensive data security systems in place. For example, our security measures meet industry compliance standards and many go above and beyond what is required by industry standards. In other words, PCI is worthless. In conclusion, it looks like some sort of a network breach (which could be anything from phishing/malware to compromise from a retail location to a full network hack). A sniffer was possibly installed, since it seems they don’t keep credit card information (again, assuming statements are true). The fraud was detected by the banks or credit card companies, then it took a little under two weeks to contain. Not great, and indicative of either a little sophistication on the attacker’s part, or a lack of sophistication on Hannaford’s part. How to prevent this? We won’t know until more information is out, but since they shouldn’t be PCI compliant if they transmitted credit card numbers in the clear, perhaps my guess of sniffing is off. I’m still laying odds on that, and if so, encryption is the answer. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Data Breach, Hannaford Share:

I just published an article on TidBITS on this very issue. Basically, I don’t think the average Mac user needs it yet. AV comes at a performance cost that isn’t justified by the risks it addresses. It isn’t that Macs are more secure than Windows- it’s that they aren’t as big a target yet, and I’m not convinced that desktop antivirus will help much once Mac malware really starts proliferating. If you are a lone Mac in a Windows environment you might need to install it to protect your Windows brethren (don’t be the vector that infects them – sending viruses you don’t even notice is not nice), and if you go to a lot of risky places you should consider it. For the record, I don’t use AV on Mac or Vista, but I do use it on XP. And if Apple is smart, they can finish off the Leopard security features and harden the platform enough that it won’t be as easy a target even as market share rises. (I was amused reading the Slashdot comments, which I usually ignore. I don’t mind the criticism, but at least read the fricking article, guys). < p style=”text-align:right;font-size:10px;”>Technorati Tags: Apple, Mac, antivirus Share:

David here again. Chris Hoff, in his often imitated but never duplicated way, recently reopened the massive can of worms that is security awareness training. Go ahead and read the comments on both posts — they are energizing to say the least. I’ve included a paper that I wrote for our customers below. Given the original audience, it’s on the more formal side. Let me know what you think…. Contrary to popular belief, Security Awareness Training need not be a necessary evil, but can instead be an effective method of communicating with and training employees. This research note will outline both the need for, and scope of, an effective security training program. Few, if any, technology professionals have ever overestimated the ability of users[1]. Others claim that user security training is useless and a waste of time and money[2,3], saying that users are plenty smart but “They shouldn’t have to worry about it. This is a technology problem.” This viewpoint is all well and good as long as the scope is limited to technological issues such as viruses, spam, and phishing attacks. The problem is that the scope and scale of user education need to be much larger for effectiveness. Like any other tool, training is not the end-all and be-all of security. It needs to be used along with sound business process design[4], solid technical controls, and strong support from the senior executive team. In an enterprise environment, user security training is not: Telling users not to open emails from people they’ve never heard of Telling users not to click on random links on web pages Telling users to patch their own systems Trying to make users change the way they interact with their tools is very challenging, and the very nature of viruses, phishing, and the like make it very challenging for users to correctly discern the difference between legitimate and hazardous emails and websites. So these are ideal problems for solving with technology. Awareness of the threats, however, is directly useful for users, as they are often the first people to notice issues and notify the helpdesk. Good security training focuses on broader problems that don’t lend themselves to pure technology solutions. Training can be broken down into two major categories, General and Group-Specific. General security training is appropriate for all employees regardless of their job role. Group-Specific security training focuses on particular skills that are relevant to only a portion of the company. Examples of General Security Training include: Education on policies and procedures Fire/Tornado Drills What to do in an emergency, e.g., how to get 911 (or equivalent); how to contact on-site security Locations of First Aid kits Who to contact if you believe you have identified a security threat or risk “If you see something, say something” Not faxing/emailing organizational charts, phone lists, or other protected corporate information offsite Rules for how to handle confidential information Travel safety tips General security training has the advantage of aligning with common-sense emergency preparedness and professional behavior. It is well-suited to mass communication channels, such as email, web-based training, newsletters and posters. Regularly reminding employees about what to do (and not to do), and how, is a cornerstone of a strong security posture. Educating users about policies and procedures is key for not only maintaining a smoothl-running operation, but is absolutely necessary from the standpoint of compliance liability mitigation. For instance, the Payment Card Industry (PCI) Data Security Standard section 12.6 specifically mandates a security awareness program[5], and although not explicitly part of either Sarbanes-Oxley or Graham-Leach-Bliley, many auditors look for awareness training programs. Regular reinforcement is particularly necessary in organizations with high turnover rates, particularly for call centers, help desks, contract or temporary staff. The need for training goes well beyond compliance requirements, however. The following examples further illustrate the importance of ensuring that everyone is aware of the appropriate information. Users are the first line of defense in the organization and they are most effective when they know what to do. Examples 2 through 6 all focus on what to do should something unfortunate happen, whether that is a minor injury, a major disaster, or anything in between. Examples 7 and 8 are about loss of confidential information and intellectual property. One financial institution discovered through an email content scanning tool that well over 99% of the time that a customer’s PII (Personal Identifiable Information) was sent offsite there was no malicious intent. These security breaches were from unintentional or accidental causes. Not realizing that recipients of the email were not inside the company, or that the file contained PII, were by far the two most common reasons that this sort of data was leaving the company. Example 9 is all about the safety of corporate personnel when traveling. This is particularly important if employees travel to parts of the world which are known to be dangerous. However, general travel safety tips can be useful to all staff when traveling. Basic reminders like not checking laptops, and use of safety pouches for extra cash and passports, can save both the employee and the company a great deal of money, time and heartache. Examples of Group-Specific Training include: Disaster recovery and business continuity planning/training for operations staff Design/architecture/coding training for the development organization Fraud detection training for finance staff Group-Specific training tends to be in-depth and should be treated like any other subject-focused training. As such, it may include dedicated classroom time or attendance at conferences to bring teams up to speed in a timely fashion. One of the many definitions of security is the process of enabling a business to run in a risky environment. Thus a CSO needs to plan for the inevitable and the unthinkable. In a major disaster, a business continuity/recovery process can be the difference between staying in business and shutting down “for good”. In a high volume commerce or call center environment, the cost of even an hour of downtime can be extremely high. Having a plan is not sufficient.

I’m out in Boston for the SOURCE conference where Hoff and I just presented on Disruptive Innovation and the Future of Security. It went well, but we’re only giving ourselves a 6 out of 10. We tried to stuff in too much content and didn’t focus as much as we should. We’ve already mapped out the next version and I wish we were giving it before June (our next scheduled show). One thing I noticed during our discussion of my section on the Information-Centric Security Lifecycle is that we’ve failed to talk about data governance. Since, thanks to Chris, I’ve become convinced that information is data with value, we’ll skip data governance and jump right into information governance. Consistent with my last short post, here are a few points on principles for information governance: The business, not IT or security, must determine the relative value of information. Information classification must represent the value of the information. Business and technical policies and controls must align with the information value/classification. Information governance must be consistent, practical, and auditable. The Board of Directors and executives are responsible and accountable for information governance, which is then implemented by business units (including IT). Information governance should not be so detailed it can’t account for new information or accurately reflect the reality of a business in motion. These aren’t quite as thought out as the Principles of Information-Centric Security, but I think they are a fairly reasonable place to start the discussion. Also keep in mind that I’m not talking about in-depth, impractical classification of every piece of data in an organization. This is about broad strokes to guide users in understanding what information has value over other information, and how that information should then be handled. You’ll also notice I didn’t mention security. Not once. Security is only one tool in the governance kit. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Data security, Governance, Information Governance, Information-centric security, Information Security Share:

I was reading an article by Rsnake this morning on the problems of using a username as a primary key, and it reminded me of something I’ve been meaning to write about for a while. As a former database designer and current security geek I’m often stunned by how often designers/developers choose really bad primary keys for their databases. Even back in my developer days, when security for me meant taking down drunks at concerts, I knew better than to use something like a username, credit card number, or Social Security Number as a primary key. To be honest, it had nothing to do with security and everything to do with good database design. Back when I was starting my IT career I was fortunate to work closely with the professor at the University of Colorado who taught database design. One of his cardinal rules was to, wherever possible, use system generated keys as the primary key. Randomly generated keys, as opposed to sequential keys that could “leak” information. Our designs should also strive to conform to at least Fourth Normal Form, although full normalization wasn’t always possible for practical reasons. We never used Social Security Numbers as primary keys because they are neither always unique (there are mistakes in the system) nor available for all potential users (foreign students were assigned fakes). Credit card numbers are bad because they are not a unique identifier for an individual- I have multiple credit card numbers, any of which can identify me, all of which are temporal (change over time). I have no idea why retailers so often use credit card numbers as all or part of a primary key, since I may use multiple cards even on the same day. Usernames more closely conform to a viable primary key from a pure, non-security design perspective, but I never liked them for some of the reasons RSnake cites, and I always feel like usernames are temporal, even when they aren’t, and while I haven’t tested it I think the performance of numeric keys is probably higher. Thus my first rule in picking a primary key, from both a pure design and security perspective, is to use system generated random keys (preferably not sequential auto increment). For other fields you want unique, like username, SSN, or credit card number, just set a unique index on the field. Worst case, you can even use this to correlate across unrelated systems assuming the rest of the attributes line up (we used to do this using the SSN, before we all learned using them at all is bad). One criticism of Rsnake’s examples of account hijacking is that even with a pure primary key, if you hard delete a username someone can still impersonate the account, depending on the design of the system. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Database Security, Information-centric security, Primary Key Share:

I’m pretty excited about speaking at the Source conference in Boston next week, despite the expected 6 hours of agony while flying with this damn shoulder. Why? For the first time, Hoff and I are co-presenting. The topic is, “Disruptive Innovation and the Future of Security”. We’re actually lining up a series of conferences together where we present this one. I’ll also be presenting my pitch on “Understanding and Preventing Data Breaches” where we dig into real-world breaches, figure out the root causes, and look at defensive measures. Should be a good time in Boston, and if you can’t make it we’ll have to catch up at RSA next month… Share: