Sister CISA CISSP:

August, 2008

Aug 27 2008   4:27PM GMT

“Over-Reacting” to Data Breach Reports



Posted by: Arian Eigen Heald
Security, Compliance, Data Breaches

After Benjamin Wright’s comments on my previous post about Best Western, I hopped on over to his blog and took a look at his point of view.

Speaking from a consumer point of view, I find cold comfort in the drop in numbers from “possibly 90 million” to “only” 40 million credit card numbers being stolen from TJX. He makes a good point about the actual theft losses (as far as we know) committed with the stolen data as “only” about $1 million, and complains about the fines imposed and the over-reaction of Banks (by issuing new cards and forwarding the resulting costs to TJX).

The problem is, the Banks can’t wait around to see which ones of the 40 million accounts are used to commit fraud, or even how many of the accounts are “finally” used to commit fraud. That number is an unknown, especially if all the cards were NOT closed out. The banks did what they had to do, and TJX should pay for it. I certainly would not want to used a card with a compromised number and the possibility of being charged for something I didn’t buy, and the resulting hassles.

Did the FTC over-react? Did the economy need a crisis in consumer confidence? Did TJX get used as a “power-of-example” by VISA?

As an auditor and engineer, it bothers me when I see that vendors don’t know who accessed their data, or how much of it was lost. It tells me good controls are not in place. See Rule # 5

I’d like to see a list of companies from VISA that are NOT compliant. Or even a list of companies that are compliant. You could check before you purchased anything online. That would motivate business, I’m sure. Is compliance the same thing as good security? Absolutely not. Just ask Hannaford. However, “It’s better than snowballs in summer,” as my father-in-law likes to say.

Back to Best Western: there IS a question in my mind as to whether the report is more hyperbole than what may have happened. It’s unclear to me. Access via one machine and one account may not have given up all the information. Unfortunately we may not get to know the truth. It would be nice to know, but it may give up too much information for Best Western to release the facts about their systems.

Benjamin is right that I may have commented too quickly. The report from the Sunday Herald leaves out a LOT of details and a lot of people on the web have jumped all over it, too. (Insanity in numbers is always helpful). So we will need to wait and see. Unfortunately, given the track record of business, it’s hard to be hopeful. I will hope I’m wrong.

UPDATED Check out Best Western’s excellent response to the incident.

Eigen - Being wrong and liking it.

Aug 25 2008   6:33PM GMT

European Hotel Chain Has Their Customer Data For the Past Year Accessed



Posted by: Arian Eigen Heald
Security, Database, Identity theft, Database security, Data Breaches, Security Devices

Visited Europe in the last year and used a Best Western Hotel? Your credit card, expiration date, the company that employs you, your name, address and future bookings may be in the possession of a Russian Mafia website. An enterprising Scottish newspaper, the Sunday Herald, noticed on Thursday night that an Indian hacker offered to sell access to Best Western and notified Best Western about the breach. Although Best Western closed the hole on Friday, the horse is out of the barn.

Eight million people stayed at 1,312 locations from 2007. Is this “Identity Theft?” It’s a darned nice start. Only the Social Security number is missing. Certainly the names, addresses, business information, details of employment, credit card numbers and expiration dates could be used for synthetic identity theft.

According to the Herald:

“The Sunday Herald understands that a hacker from India - new to the world of cyber-crime - succeeded in bypassing the system’s security software and placing a Trojan virus on one of the Best Western Hotel machines used for reservations. The next time a member of staff logged in, her username and password were collected and stored.”

One of the first things I learned doing penetration testing was that you don’t have to have some fancy piece of coding to break in. It can be the simplest thing - finding a set of keys in someone’s desk - that gets you into the server room. In fact, it usually IS the simplest thing. Their web site may have great security, but that was easily bypassed by a user login.

Best Western evidently had not noticed all the activity that account was generating - sucking all the data out of their databases. Which takes us back to auditing databases, doesn’t it?

Best Western’s response? Tim Wade, head of marketing for Best Western GB, said it was “unlikely” that whoever was responsible got hold of the details of “every booking at every hotel” in Europe because of the way their system worked. Has anyone mentioned to Best Western that letting a marketing guy handle communications for a data breach is not always the best choice? “Unlikely” is not a word that I find comforting. What are the facts? Why don’t they know exactly how much was taken? Because they probably don’t have any security logging in the right place. It’s why they didn’t notice the breach in the first place.

Let’s hope they didn’t get all the way into the American side of the company. Or maybe they have. How would we know?


Aug 21 2008   3:48PM GMT

How to Audit Databases: Part I



Posted by: Arian Eigen Heald
Security, SAP, Oracle, Compliance, Database, SQL Server, Identity theft, DataManagement, SOX, Database security, Data Breaches, PCI DSS, IT audit, Admins and Auditors, SAS 70

Databases are enormous, powerful repositories of data. They can hold payroll, HR personnel data (think social security numbers) stock prices, Accounts Receivable, Client Relationship Management, and customer information. Banks can’t live without them. Most medium and many small sized businesses use them, too.

They are the motherlode of the organization and the last line of defense in a hack. It’s critical that DBAs have the tools at their disposal to monitor and provide reporting. If your database isn’t secure, the hacker won’t care how well indexed it is.

And there are a lot of ways in. If I have administrative access to the server, I can copy all the database files, take them away and reload them on my own database server. If I have unencrypted backups of those files, I can do the same thing.

So the first step in auditing the database is to examine the server the database is running on. This gets confusing to non-DBAs and auditors because many of the terms used inside the database are similiar to server terms. It’s important to keep them separate, and to make sure that access to the database files on the server is monitored. Server administrators do not need to have access to those files, but they may have to, in order to manage/backup the server. So, set up logging.
Make sure everyone who has a need to access that server administratively has a unique ID. Remove access to root(*NIX) or Administrator (Windows). They can have administrative rights, just make sure you can identify them by ID and IP connection.

Finally, what about the backup tapes? If they are not encrypted, you can join the “breach list” of companies that have lost their data when tapes were misplaced, stolen, or “disappeared.”

NEXT: Inside the Database “Server”


Aug 19 2008   1:20PM GMT

I Can Make Your Database Lie to You



Posted by: Arian Eigen Heald
Security, SAP, Oracle, Compliance, Database, SQL Server, Identity theft, DataManagement, SOX, Database security, Data Breaches, PCI DSS, IT audit, Admins and Auditors, SAS 70

So many financial auditors, CEOs, CFOs and others rely on electronic data to understand the complexities of General Ledger, Accounts Payable, etc. In this era of SAP, ADP, electronic time clocks, etc., the one common denominator is the database underlying each application.

Applications aren’t something you just run on one PC anymore (I know I’m preaching to the choir, here). Financial applications, especially, are all networked, and the storage is usually a relational database like Oracle, MS SQL, Sybase, DB2 or MySQL. Relational databases are wonderful for business because you can correlate so many different facts.

So why are they so scary to me? Because they are rarely audited.

I need a network ID to log in, so the database is safe, right? No.

The application has security controls, so my database is safe, right? No.

DBAs (Database Administrators) know exactly what I am talking about here. All those items are just the outer edge of security. If I have a network jack and a database ID and password, I can bypass those controls easily.

Some applications have a database ID and no password, or an easy-to-guess password. And very frequently, that ID has access to everything, including reads, writes and deletes.

If I have that ID and a network jack, I can log into your database using ODBC, Microsoft’s Open DataBase Connection client software that is installed by default on Windows operating systems. I can use Excel, Access, or other database software to pull all your data out.

Or change your data.

And P.S., connecting with ODBC uses clear text usernames and passwords, which is how I once captured a DBA’s ID and password with a sniffer.

Fortunately for all of us, there are usually other financial controls that can capture errors or changes in the database. Usually.

NEXT: How to Audit Databases


Aug 14 2008   10:19PM GMT

Let’s Not Overuse “Identity Theft”



Posted by: Arian Eigen Heald
Identity theft, Data Breaches, Admins and Auditors

I’ve noticed lately that the press has started applying this term liberally when data is stolen. Data theft is NOT the same thing as identity theft. (And when did we start capitalizing it, by the way?) Data theft does not equal identity theft, because not all data that is stolen is used to acquire someone else’s identity.

What comprises identity theft? Someone who has taken on your personal information in order to become you in the eyes of financial entities. Your identity is used to rob you. It’s much nastier than having your credit card replaced by your bank because a business has been hacked or had a trusted insider steal data. As unpleasant as that is, it is not in the same league as having to spend hours contacting police departments, credit bureaus and banks to try and correct your personal financial history. Or even being arrested because there are warrants out for fraud committed in your name.

I noticed this during the announcements for the indictments of 11 people that variously referred to “A massive case of identity theft,” or “11 Identity Thieves indicted….” Feds charge 11 in largest Identity Theft Heist..”

“Identity Theft” has become an overused title for news articles and a marketing ploy for another generation of businesses that sell “free” credit reporting, “identity protection” and other similar items.

Google for “Identity Theft” and there are over 21 million entries; google for “data theft” and there are “only” 1 and a half million or so. Interesting, isn’t it?

Now if you do the same thing, and remove all the dot com (business) entries for “identity theft,” you get a much smaller sample. Less than half.

The results are equally striking for “data theft” without the dot coms.

Isn’t marketing grand?


Aug 13 2008   1:53AM GMT

Monitoring Insider Access to Databases



Posted by: Arian Eigen Heald
Security, Database, DataManagement, Database security, Data Breaches, Admins and Auditors

The recent report on the Countrywide data theft got me thinking again about how to monitor insider access to databases.

The story is that the thief had access to the Countrywide (a mortgage broker) set of databases, which, of course, held all sorts of private financial information. A treasure trove, in fact, for anyone seeking a quick buck on the Internet. Countrywide is owned by Bank of America, and I have to wonder if they had done a third-party vendor review anytime recently, or had relied on Countrywide telling them everything was secure (which lots of Banks do, despite the Office of the Comptroller of the Currency telling them NOT to do that).

According to Countrywide, “The thief took advantage of a lapse in policy.” What interesting language. What policy, exactly, and what defines a “lapse?” Sounds like nobody was really paying attention to database access. Did Countrywide or Bank of America discover the thief? No, the FBI did.

What would it have taken to catch the thief in the act? Given that the thief was a “senior analyst,” it means that controls would have to be really specific. Let’ s brainstorm a little bit, because we need to start thinking this way. Too often, insider access is left wide open, and excuses are made that “it’s too time intensive” or “it takes resources away from the server.” Those excuses will no longer hold in court of law.

Think about it: if your organization offers up those excuses, the judge will jump all over you. If you have done background checks and are monitoring access, a lot of time and money will not go to lawyers. Demonstrating “due diligence” with regard to your employees and your data is very effective.

So, how could we monitor that kind of data? Two thoughts occur to me: first, only allow the employee to access records he works directly with, and require approval for access to any other records. This won’t rule out collusion, but it will make it harder for a single thief.

Second, log use of flash drives. This could be “silent” logging, but you could put two and two together, if the databases were also logging access.

How would YOU catch him?


Aug 7 2008   4:39PM GMT

Kill Your WEP Now



Posted by: Arian Eigen Heald
Wireless, Security, Compliance, Data Breaches, PCI DSS

The announcement on Tuesday that indicted 11 people for “the largest data breach in history” was an interesting read:

The indictment returned Tuesday by a federal grand jury in Boston alleges that the suspects hacked into the wireless computer networks of retailers including TJX Cos., BJ’s Wholesale Club, OfficeMax, Boston Market, Barnes & Noble, Sports Authority, Forever 21 and DSW and set up programs that captured card numbers, passwords and account information.

What was the common technical denominator of the attacks? Wireless networks. Think wireless cash registers, connecting to local servers, and from there transmitting the information to corporate databases.

TJX had no firewall between their insecure wireless network and their corporate network. They were using WEP, a wireless protocol that can be cracked with trivial (10 minutes) effort.
BJ’s failed to encrypt customer data when transmitted or stored on BJ’s computers, kept that data in files accessible using default passwords, and ran insecure, insufficiently monitored wireless networks. (There was an unsecured access point at a store).

Although the Attorney General said that “They used sophisticated computer hacking techniques that would allow them to breach security systems,” later on the Feds commented that
“The alleged thieves weren’t computer geniuses, just opportunists who used a technique called “wardriving,” which involved cruising through different areas with a laptop and looking for accessible wireless Internet signals. Once they located a vulnerable network, they installed so-called “sniffer programs” that captured credit and debit card numbers as they moved through a retailer’s processing networks.”

So they drive around, found the signal they could crack, installed sniffers and probably got all the way into corporate networks. You have to know that sniffing would not capture millions of numbers - I’m still betting they got into corporate databases. All it takes is one open wireless access point if you don’t have them secured from your network.

Sadly, of the 11 people indicted, only three are in custody in the United States.


Aug 5 2008   4:46PM GMT

ATMs - Automated Theft Machines



Posted by: Arian Eigen Heald
Security, Identity theft, Security Devices, Hardware & InfoSec, Eigen's Rules of Thumb, Automatic Theft Machines

It’s absolutely fascinating (in a nerve-wracking sort of way) to read about how many different ways there are to use ATMs to capture (and steal) accounts and PIN numbers. From there, it takes very little time to create a fraudulent card and spend what you can before the bank catches up. It’s a triumph of hardware over software. Thieves simply work around the software controls to capture the information they want.

For example, the concept of “skimming.” Typically, thieves attach a device to the outside of the ATM that records the magnetic stripe information as you insert it. They also need a camera of some sort to capture the PIN as you type it in. For a classic example, with pictures you can see that the card skimmer fits in front of the regular card slot. For PINs, the clever placement of a pinhole wireless camera makes it all way too easy.

Thieves tend to get endlessly creative: One fellow bought his own ATM equipment and kept moving it around from place to place in order to capture information. He was good enough at it to collect at least $4 million, and is still at large.

More losses come from retail ATMs (those found in supermarkets, convenience stores, gas stations, or other non-banking environments) where there are less stringent controls and only casual observers. In May of this year, the ATM at one gas station was rigged, with at least 80 victims. When he was finally apprended, he had stolen more than $185,000. Ouch.

There are about 360,000 ATMs in the United States, according to Bankrate.com Only half of them are at a bank.

The ATM designers are moving to internal card readers and other techniques to eliminate external skimming devices, but when you can buy your own ATM and move it around, controls on sales of such machines must be tightened.

Rule of Thumb: If I don’t go to the bank for gas, I won’t go to the gas station for money.