July, 2008

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

According to an article on MSNBC.com, 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.

What NOT to call SAS 70 Reports

I ran across the new website “securityidiot.com” 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.

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

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.

Does Your School or University Take Credit Cards?

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.

** 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!

SAS 70 Reports - Section One

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.

Why?

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.

SAS 70 Reports - Reading What You’re Getting - From The First Page On

So you have this report from the company you’ve outsourced a critical financial service to, and it looks like a lot of boilerplate with a chart of sorts at the end. What are all those sections for, and why should you care?

First, determine that the company performing the report is a certified public accounting firm. This is the only legal entity permitted to perform a SAS 70 type audit, regardless of whether it is a Type 1 or a Type 2. Other firms can perform SAS 70 “readiness assessments,” but not the SAS 70 exam itself.

The first page can tell you whether it is a Type 1 or Type 2 audit. The subtitle:

Report on Controls Placed in Operation
and Tests of Operating Effectiveness
Prepared in Accordance with
Statement on Auditing Standards No. 70

indicates a Type 2 by virtue of the statement “Tests of Operating Effectiveness.” If you’ve read a previous column, you know that a Type 2 looks at controls and tests those controls. That’s a Good Thing.

The next thing you should see on the first page is an indicator of when the controls were tested. The date range is commonly a year, but it can also cover a six or nine-month period.
This means the auditors have tested controls over that time period to see if they were actually in place and effective.

Consider how long ago that date range was. Some organizations will attempt to use a SAS 70 report that is two or three years old. Regretably, some auditors will take 4-6 months to issue a report - which can mean that what you’re looking at has limited value. The longer the period from the actual test of controls, the less value the report has, because it cannot report on the current state of controls.

“SAS 70″ - It Pays to Actually READ What You’re Getting

When I do an audit and request that my client give me SAS 70 reports from his/her critical financial vendors, I am often amazed (or appalled) at what I get to read.

My team performs about 20-25 SAS 70 Type IIs every year, and maybe 2 SAS 70 Type I exams. Why the big difference? Type II exams actually test the controls the service organization says it has in place. In a Type I, all we test is that the company says it has controls, and that those controls appear adequate. BIG difference. It’s also a big difference in price for the service organization, so that companies try to get a Type I if they can.

Sometimes a service company will start with a Type I, planning to go to a Type II. I’m inclined to recommend getting a SAS 70 readiness assessment, then completing a Type II - it saves money and makes clients happier. More on this later.

Also, Type I exams only look at what control procedures are in place at the time the service auditor comes to visit (called “Point in Time,” appropriately enough). They can throw out the controls the day after that. So this type of SAS 70 has limited value to clients (your company).

For Type II exams, we test over a period of time, say the six months, or nine months, or 1 year previous, to ensure that the controls were in place and effective. The downside is that it is previous time testing, so if the controls fall apart three months after the test, I can’t report that until (or if) I come back for the next test. But it does give considerably more assurance that controls are in place, if you can see that in the previous year what we have tested is in place.

SAS 70 exams must be signed off on by a certified public accountant, even if CISAs are doing the testing on site. Make sure the company that did the test for your outsourced service is exactly that. Otherwise, the report is not legal in a court of law.

I have seen proposals (just two weeks ago, from a very big service company, as a matter of fact) that announced they were “doing” a SAS 70 as part of their security; number one, they can’t “do” one, and number two, a SAS 70 isn’t a “security” exam.

It’s an exam to provide reasonable assurance to the client company’s internal financial auditors.

So, when reading the report, you’ll want to pay attention to the sections that describe what they’re doing to protect YOUR data. If your company is using a specific application over the web, what are they doing to provide safeguards for your data on that web server or database?

A little over a year ago I reviewed a report on exactly this issue; the report tested the office Windows Domain for good control practices but never addressed any controls over their application web server: a Linux box. (Scary, isn’t it?)

There’s generally several sections to the SAS 70 report, and it’s worth knowing what to look for in each section. We’ll touch on that next.

SAS 70 Reports - Why Should You Want One?

There seems to be a lot of mis-information about what a SAS 70 report is - just today I came across a post that referenced being “SAS 70 - compliant.” There is no such thing. There is no pass/fail aspect to a SAS 70 because the Control Objectives and Control Procedures are designed by the client. It’s hard to flunk a test you designed for yourself (although I’ve seen lots of companies that do it).

A Statement on Auditing Standards #70 is used exclusively by service organizations that provide a critical financial service to their client businesses.

For instance, if your company outsources health care management to another company, your company will want a SAS 70 report from the health care management company. Why? (For starters, it’s good to know your health care mgt company takes good care of your money and personal health information.) Because your internal financial auditors are going to demand you get one from them. Health care management costs a lot of money and can have a big impact on your company should they not have good practices in place.

SOX regulations require that companies that outsource services that provide a critical financial function have a SAS 70 from that company. Banks are required by the FDIC to have SAS 70s from any service that provides a critical financial function.

So, your internal financial auditor is asking because he/she must meet regulatory requirements. Any time your company outsources a service that is deemed a critical financial service to the company, they should be asking for a SAS 70. And not just any old SAS 70.

Making Software Developers Clean Up Their Act

In the course of many audits and pentests, I can’t tell you how many times I have found flaws and openings based on bad development practices. It’s downright painful. And yet software keeps coming out with the same problems. I know WHY this is happening, but I can’t stop it. YOU can.

Have you ever been in the position of having a software vendor say: “We’re not going to test that patch yet, you’ll have to wait for the next software release from us. If you patch it, we won’t support it.”

Or finding a security flaw in the application, reporting it to the vendor, and having them say they will charge your company to fix it as a “feature request.”

Or examining roles and rights in the database, and finding out everyone is sysadmin. Or better yet, the developer hardcoded his ID into the application.

I bet you have, and you know I have. Once the software is installed and in production, they have you over a barrel and they know it. Time to build a better barrel.

Time after time, I’ve found software applications that don’t secure the application user inside the database (giving that user rights to EVERYTHING). Why? Because it’s easier to code. You don’t have to spend time finding out what broke and fixing it when you lock user rights down. Some applications hardcode usernames and passwords right into the software so that it can never be changed (unless, of course, you pay for an upgrade). Even worse, I’ve seen it when the ID is hardcoded with a blank password. Why? It’s fast, cheap and easy.

How do YOU change it? Two ways:

First, raise management awareness so that you are at the table with the software salespeople to ask some hard questions. Is security part of their SDLC (Software Development LifeCycle)? Management can often be “wowed” by a product without ever looking under the hood. Ask how their product is secured, especially since it will probably be holding important data. Don’t be wowed by application level controls - get some hard answers on how the data is accessed.

Second, be there at contract time. This is the most important. Make sure it is written into the contract that they will fix all security flaws found in their product within 30 days. Make sure that they are responsible for testing OS patches quickly and reporting to you if it is OK to patch. Pick a timeline you can live with. After all, you’re paying them for a service.

If not, you’ll have to live with buggy code and I’ll have to audit it. We’re in this together.