August 19, 2008  1:20 PM

I Can Make Your Database Lie to You

Arian Eigen Heald Arian Eigen Heald Profile: Arian Eigen Heald

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

August 14, 2008  10:19 PM

Let’s Not Overuse “Identity Theft”

Arian Eigen Heald Arian Eigen Heald Profile: Arian Eigen Heald

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?

August 13, 2008  1:53 AM

Monitoring Insider Access to Databases

Arian Eigen Heald Arian Eigen Heald Profile: Arian Eigen Heald

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?

August 7, 2008  4:39 PM

Kill Your WEP Now

Arian Eigen Heald Arian Eigen Heald Profile: Arian Eigen Heald

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.

August 5, 2008  4:46 PM

ATMs – Automated Theft Machines

Arian Eigen Heald Arian Eigen Heald Profile: Arian Eigen Heald

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 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.

July 31, 2008  8:33 PM

Losing Your Credit Card Number at the Airline Check-in Kiosk

Arian Eigen Heald Arian Eigen Heald Profile: Arian Eigen Heald

According to an article on, there has been a data breach at the Toronto, Canada airport that may have been through the check-in kiosks. Similar to my blog on instant photo machines, the ability of machines to take more information than they need is certainly something that manufacturers should address, and quickly.

One airline at the airport has already suspended using credit-card information to check in, so even though a “full report” has yet to come out detailing HOW, we can draw some conclusions based on that action, and this statement:

“But Scott Armstrong, spokesman for the Greater Toronto Airports Authority, which owns the machines, said investigators inspected the devices and found no signs of tampering. That suggests the data was collected by the machines and stored somewhere, then stolen by hackers who managed to access it – either directly or through the network that connects the kiosks to the airlines.”

That is a logical conclusion, if skimmers were not attached. Given that the skimmers would have to be inside the machines in order not to be really obvious (if you travel a lot, like I do, you know what they look like.)

But what is the most disturbing is how the airlines and kiosk makers are taking turns not commenting. There are over 70,000 self-serve kiosks in American airports, that actually capture and send ALL the mag stripe data during the course of check-in to the airline. What do the airlines do with that data? How is it transmitted?

What do you want to bet that a technique similar to Hannaford’s data breach is in play?

Is this covered under the PCI DSS credit card regulations? Probably NOT, because no charges were made. And it’s an internal network, so encryption would not be required.

Why were they capturing ALL the stripe data? Because they can. Because it’s easier to program than eliminating “some data.” Because no one thought about the security of the data the machines were handling.

Keep your credit card in your pocket when you check in. That’s where mine will be.

July 29, 2008  11:16 AM

What NOT to call SAS 70 Reports

Arian Eigen Heald Arian Eigen Heald Profile: Arian Eigen Heald

I ran across the new website “” in my travels, and was reminded that it is so important to be able to laugh at yourself (and others!). It’s so easy to turn a Bad Idea into Bad Technology, these days. Or worse, another new acronym.

You should especially check out the rant on InfoSEC SPEEK that had me ROTFL. (Are “old” acronyms still OK? Or just old?) Between the hackers, the vendors, and our own pretentiousness, don’t we really have to wonder how anything really gets secured?

For example, following up my previous posts about SAS 70 audit reports:

“SAS-70 Certified” (They obviously haven’t read their own report. Maybe that’s a good thing for the rest of us.) I went to Google, just for fun, and searched on the topic after seeing one such statement in an RFP (Request for Proposal). There are an astounding number of responses for businesses that are listing themselves that way. Has no one ever told these folks that there is no such certification???

“CompanyName participates in an annual audit performed by an independent accounting and auditing firm and receives confirmation of our continued compliance with SAS 70 standards.” What standards? What compliance? It’s their own controls that were tested. Where are they getting this stuff? It’s almost painful to read.

Or, in a total munge of regulations:

“AnotherCompany, a premier provider of back office, accounts receivables and financial services announced that it has received full SAS 70 certification. This fulfills Section 404 of Sarbanes-Oxley, the corporate governance accounting mandate.” Wrong added to more wrong. SOX is not a mandate, a SAS 70 audit does not fulfill Section 404, and it’s still not a certification.

Then there’s the businesses that market themselves as having “passed” or “earned” a SAS 70. Writing your own test and passing it – Wow. What an accomplishment! For our sakes, I hope it was an “A” grade and not a “C.”

BAD marketer. BAD.

It also calls into question the quality of the organization. I don’t know about you, but reading that sort of publicity announcement from a Data Center would make me really nervous about putting my data there. And if you search those terms together on Google, there seems to be an embarrassing number (more than zero) of “Data Centers” that are doing just that.

The same feeling would apply for outsourcing my financial processes with the accounts receivable/financial services people. Some medical benefits administrators have “passed” and “earned,” too.

And it’s REALLY embarrassing when a public accounting firm offers such a “certification.”

Ouch. It hurts when I laugh.

July 24, 2008  8:37 PM

SAS 70 Report: Section 2 – What to Look For in This Section

Arian Eigen Heald Arian Eigen Heald Profile: Arian Eigen Heald

In this section of the report, it is common to find it titled “Description of Controls Provided by (Company Name).” The company being audited provides a narrative description of itself, their critical applications (usually the ones providing a service to clients) and general controls. Often, the service auditor will assist in the write-up of this section, but legally, it is the responsibility of the company to determine that what is in this section is correct.

You will want to review carefully the subsections on their organizational structure, and how they manage new employees. Do they provide annual security training? Are background checks used? How do they add and remove users?

The subsections on critical applications should have processes in place to add and delete users, as well as a periodic review of users to make sure there is no “access creep.” (Where people move departments and keep both their new access and their old access.)

Review their Change Managment/SDLC (Software Development Lifecycle) subsection to see how diligent they are in testing code before it goes into production, and if their testing process is documented. They should have software that acts as a code repository and controls code changes. Programmers should not be moving code into production systems. If they only have off-the-shelf software, they still should be managing updates and patches.

For network management, they should be fairly specific about common practices, such as password controls, patching servers, routers and managing firewalls.

There should be a section on physical and environmental controls. This should include access controls, fire alarm systems and power redundancy. Sometimes this area in the narrative will include backup controls as well. Where are they storing their backup tapes with your information? Is transport of those tapes secured? How about disposal of hardware and paper documentation? This can be really important when the SAS 70 is covering a medical services bureau, for instance.

Make sure the narrative addresses your how the service bureau protects systems that hold your company’s assets. If they only assess the Windows domain, and your data is on a Linux server in the DMZ, how do you know how secure your data is?

In short, look for what isn’t there.

July 22, 2008  4:32 PM

Does Your School or University Take Credit Cards?

Arian Eigen Heald Arian Eigen Heald Profile: Arian Eigen Heald

The Payment Card Industry (PCI) Data Security Standard (DSS) has taken many educational institutions by surprise. If your College or University accepts payment cards on campus or online, you must comply with this standard designed for safe handling of sensitive consumer information. Examine such areas as tuition payments, fees and the campus bookstore.

So here are some tips for assessing what risk you have with the DSS:

Know Your Total Transactions:

How many credit card transactions does your institution generate per year? This includes all the credit cards together, not separately. “All” includes Visa, MasterCard, Discover, American Expres, and Diners Club. It no longer matters whether the transactions are online or at a physical storefront. Make sure you can identify the different banking relationships that support the different cards.

What is Your “Merchant Level*?” If you are accepting credit card payments, the PCI considers you a “merchant.”

Level 1. Any merchant-regardless of acceptance channel-processing over 6,000,000 Visa transactions per year.
Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.

Level 2. Any merchant-regardless of acceptance channel-processing 1,000,000 to 6,000,000 Visa transactions per year.

Level 3. Any merchant processing 20,000 to 1,000,000 Visa e-commerce transactions per year.

Level 4. Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants-regardless of acceptance channel-processing up to 1,000,000 Visa transactions per year.

** Any merchant that has suffered a hack that resulted in an account data compromise may be escalated to a higher validation level.

You might be surprised at how many transactions you really have in your environment.

Know the Requirements:

Some institutions believe that because they are nonprofits that they are not required to meet DSS requirements. Other businesses believe that because they out-source their credit card transactions, the requirements do not apply to them. None of these statements are true.

Any organization that uses credit card transactions is responsible for meeting the standards. If your institution outsources transactions to a service provider, you must make sure that the provider has met the PCI standards. These standards apply to all entities processing or storing credit card numbers, Web-based or not. This includes database companies, telemarketing firms, or any firms that may be storing cardholder data for you.

The compliance requirements vary depending on what level of transactions (how many in total) are taking place.

Compliance Validation Basics

In addition to adhering to the PCI Data Security Standard, compliance validation is required for Level 1, Level 2, and Level 3 merchants, and may be required for Level 4 merchants.

Validation requirements and dates are determined by the merchant’s “acquirer.” That’s the bank that holds the agreement with your school or university to process credit transactions.

A table of requirements can be found here.

Know Your Data:

Determine exactly what your institution is storing from each credit card transaction. Make it practice to not retain sensitive cardholder data and encrypt all sensitive data stored on your institution’s systems.

Many older “cash” registers keep all the information on the credit card magnetic strip, or send it all to a local server, which is contrary to PCI standards. Department store TJ Maxx was storing all the data from the credit cards. When it was discovered that their security had been breached, the resulting fines and costs are well into the millions of dollars and still rising. If they had stored only the required numbers, the thieves wouldn’t have been able to use the information, and the reputation and financial damage to TJ Maxx could have been avoided.

Know Where Your Data Is:

Tracking where all the data is, who has access to it, and how it is transmitted to various parties is one of the best ways to indentify security issues. Organizations that run a software scan to determine compliance are missing the point. There is no software that can find all the places that PCI data is stored, how it is secured, and who has access to it. This can sometimes be a time-intensive search, but is well worth the investment to secure your data.

Sometimes universities have multiple credit agreements with acquiring banks and don’t realize that they have a far higher transaction count. Don’t wait to be surprised!

July 17, 2008  6:56 PM

SAS 70 Reports – Section One

Arian Eigen Heald Arian Eigen Heald Profile: Arian Eigen Heald

Commonly, a SAS 70 Type 1 report contains three sections, and a Type 2 has five sections. That because a Type 2 tests the effectiveness of the controls that a Type 1 says are there.

The first section, the “Independent Service Auditors’ Report,” is basically a letter by the service auditor (the CPE firm performing the SAS 70 exam) to the management of the service company (the company being tested in a SAS 70 exam) providing an opinion, with some standard legal coverage, on the quality of the controls in place at the company.

The paragraph after that, if the report is a Type 2, will also express an opinion based on the tests performed as to the effectiveness of those controls. There will also be a disclaimer that the report only provides reasonable, not absolute, assurance that the controls were in place and operating effectively.


When performing a SAS 70, the auditors are dependent upon what the service organization gives them for information. When I perform logical controls testing, I must ask the service network administrator to give me the information I need for an assessment. We must rely on what the service organization provides us. We do not test the environment directly. Most organizations are loathe to let some auditor have admin rights and go wandering around their network. How, then, do we ascertain the correctness of the information?

The short answer is in the contract. SAS 70 auditors will indicate in a contract for services and in the report that they base their opinion on the information they are given. The onus is on the service company to provide true and accurate information to the auditors.

So this is not a “true” security audit, in the sense that we are not directly testing the environment. (And P.S., only a CPA can perform an “audit.” Everything else is an “exam” or a “test,” or an “assessment.”) But remember that this is a report for your company’s financial auditors, so that they can determine whether the outsourcing agreement with the service bureau is protecting your company’s assets.

But can’t the service company lie to the auditors? Sure. But they take the risk of having their socks sued off if they are committing fraud. That’s also why the financial auditors perform a financial “due diligence” on outsourced companies on an annual basis to make sure they are on sound financial footing. The SAS 70 report is just part of the due diligence to protect your company.

On to the next sections.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: