Sister CISA CISSP:

Compliance

Jun 30 2009   5:12PM GMT

MasterCard Ups the Compliance Quality of PCI DSS



Posted by: Arian Eigen Heald
PCI, PCI DSS, Compliance

I’ve written before about how the Payment Card Industry’s (PCI) Data Security Standard (DSS) has some loopholes that make it easy to look “compliant” and therefore “secure. In order to comply with the DSS requirments, merchants can do one of three options:
1. their own self-assessment report signed -off on by a C-level management officer;
2. hire auditors to do a self-assessment and report the C-level can sign off on;
3. or hire an independent, PCI-accredited QSA firm to provide an independent assessment and report to their acquiring bank.

Consider that the QSA firm is required to have liability insurance, pay a hefty yearly fee to the Consortium and provide an independent assessment. Chances are the independent firm will work harder to make sure their report is accurate (given the stick that the PCI hangs over their heads of ultimate liability).

It costs merchants a lot more to have the report done independently, and they can’t hide security problems as easily. Just the fact that they have the do-it-yourself option in two out of three doesn’t give me confidence in their reporting. Any time organizations “self-assess,” there can be an enormous opportunity for fraud by the unscrupulous.

Interestingly enough, MasterCard has decided to remove the “self-serve” option from Level 2 vendors by December 31, 2010. Under the new rules, Level 2 merchants must hire a PCI-approved auditor to complete an annual on site data security assessment by Dec. 31, 2010.

Previously, those merchants were only required to complete an annual self-assessment questionnaire in order to comply with MasterCard’s Site Data Protection Program. The Payment Card Industry Data Security Standard (PCI DSS) forms the baseline for MasterCard’s Site Data Protection Program.

Will PCI’s DSS begin requiring it as well? Is this a move to test the waters? I hope so. Even though VISA says it has no plans to do so, the PCI standards board has a lot more power to remove poor QSA’s than try to assess an internal team.

Jun 26 2009   2:03PM GMT

The Tangled Ethics of the Payment Card Industry DSS



Posted by: Arian Eigen Heald
Admins and Auditors, PCI, Compliance, information security

I just finished reading an absolutely terrific article from a sister auditor who is now on my short-list of must-reads. She’s got a great name (Gunn) and a killer sense of humor (sorry, I could NOT resist).

“Why Suing Auditors Won’t Solve the Problem”
is worth a read for her point of view on what it’s really like in Audit-Land.

A bank that was impacted by a data breach at a merchant is suing the QSA firm that performed the PCI exam and signed off that the merchant was compliant. They want to recoup the money they lost from replacing all the credit cards to their customers and dealing with related fraud from the breach.

Her point of view presents the difficulties auditors have in providing reports and doing exams, as well as the foibles of various firms.

It’s a painful, but absolutely true description of how clients can respond to auditors when they don’t get the exam results they like - “Throw the bums out, and hire better (meaning cheaper AND more cooperative) ones!” As well as pushing a report documenting problems to the circular file.

What is equally painful is that there are certainly “security auditors” out there who are more than willing to do the “check box” report, collect their check, and hit the door. They are usually the cheapest bidder, by the way.

She makes an interesting point about PCI auditors, however. In order to be compliant, merchants can either do one of three options: their own report, or hire auditors to do a report they can sign off on, or hire an independent, licensed QSA firm to provide an independent report, on their behalf, to their acquiring bank, which until recently did not have to forward the report to the Credit Card Consortium.

Consider that the QSA firm is required to have liability insurance, pay a hefty yearly fee to the Consortium and provide an independent assessment. This requires a firm with pretty deep pockets (a juicy candidate for a lawsuit) and a good skillset of people. Staff of a QSA firm must have at least 10 years of experience and a CISSP running the assessment. As a result, the number of QSA firms is limited to large audit/accounting firms and security companies.

The challenge is that the client they are assessing is also paying their bill. And most of the security companies doing PCI exams also sell security products. Two fundamental conflicts with true independence, don’t you think?

Most merchants tend to do the internal self-exam, where they can manage their own report or hire a firm to do the report they can then sign off on. This means they may hire firms that do not have the same level of experience to get the job done more cheaply. See Eigen’s Rules of Thumb numbers 1 and 6.

The second challenge is that merchants can change the configuration that was tested a week after the QSA firm issues a report.

Perhaps the most fundamental issue is the public’s expectation that PCI compliance = a secure architecture that protects their information. Given that a large percentage of merchants are only partially compliant (meaning that they have met some, but not all, of the requirements and have a plan in place to be compliant at some point soon, i.e., TJMaxx, and we can see how that worked) and most merchants are doing the internal exam, there is generally a recipe for chaos.

Acquiring Banks, of course (meaning those banks who have acquired, and are supposed to manage merchant accounts) are placed in the role of security monitor by the Credit Card Consortium. They also levy fines (the ones handed down by the CCC) and set timeline requirements for PCI compliance.
Can they cut off a merchant who is making the Bank loads of money for not being compliant? Yes. Are they likely to? Probably not.

Consider that if a merchant is not fully compliant, their level of security is below the minimum. Would I want to give that merchant my credit card info? Probably not. The merchant would start to lose business based on that poor reputation, which is why PCI doesn’t publish a list of merchants who are fully compliant.

Confused yet? Me, too. Use cash and checks. Preferably cash.

So what is a poor admin to do? Focus on securing the systems under your purview and documenting your efforts. If you’re doing the job you know you should be doing, sooner or later, when the auditors show up at your door, your efforts will be validated and you can sleep at night.


May 23 2009   10:25AM GMT

When a Control is NOT a Control or, “It’s Good Enough”



Posted by: Arian Eigen Heald
Admins and Auditors, IT audit, Compliance, Steps to an Easy Audit

I run into an awful lot of engineers who hate paperwork (I feel the same way.) They are busy fixing problems, building new application support and dealing with upper managers who have no idea what they’re asking for, clueless users and now I come along to top it off asking for a bunch of documentation.

Been there, done that.

I gently explain, after I have corrected their misapprehension that auditors know nothing about IT, that if it’s not written down, it doesn’t exist. I know some engineers who believe in job security that way, but the fact is it just makes it harder for the next person to step into that role. That role will always exist. So why make it easier for the next person? Sooner or later, that next person will be you.

Why write down how a server should be built? Why write down how the servers get patched? Why bother changing the administrator password on all the servers and a different one on all the workstations? Why check to make sure that the anti virus server is actually updating all those machines? Why test to confirm that the group policy for downloading patches is actually working, and how to do that?

It’s part of being a professional engineer. It’s part of all the certifications we have signed off on; that pesky ethical paragraph that asks us to be responsible, dedicated and at the top of our game whether the job asks for that, or more commonly, does not.

It’s also a really great way of showing just how much work you do.

“Good Enough” is short for “Good Enough to Get Hacked.”

Bottom line? When you are sitting in front of a judge testifying as to what steps were taken to secure your organization, you WILL be asked what policies, standards and procedures you were following. If you have none to give the judge, you will be roasted by the jury, and your company will lose its case.

We can blame the company for not “making” us do it, but that’s not the real deal, is it?


May 6 2009   5:30PM GMT

Watching Your Data Evaporate in the Cloud



Posted by: Arian Eigen Heald
cloud computing, Data Center, "How Do You Know?", Compliance

“Cloud” computing continues to beat the drum of “cutting costs.” Although I must say that I am hard put to differentiate between “cloud computing” and data centers that host hardware, the emphasis seems to be on shared server resources and supposedly quick turnaround for new applications.

In my experience, “quick application development” is usually another way of saying “open everything up to make it work,” followed by “oops.” Or “ouch.”

The giants (Amazon, Google and IBM) are promising to customize security for their clients, but I have yet to see a price tag on that promise, or a standard for security in a cloud. I suspect that there isn’t one, and isn’t likely to be one.

Here’s some questions that keep me wondering:

How would they implement different levels of security on the same hardware/server OS?
How do I know who else is sharing my server?
How do I know that my confidential data is secure? (Think PCI and HIPAA)
How would I handle eDiscovery?
Who maintains logs - specifically audit trails?
How does handing off security to a third-party affect compliance?
Where is my backup data?
And, uh, what happens if the cloud vendor goes belly up?
Who is responsible for a data breach?

Faster, better, cheaper - pick TWO.


Feb 17 2009   6:44PM GMT

“Electronic Medical Records” or “Ready - Fire - Aim!”



Posted by: Arian Eigen Heald
Compliance, HIPAA, data security, medical identity theft, Privacy

What happens when we build a national database, with everyone’s health records? Will everyone get better, less expensive healthcare? That’s the impetus for funding a portion of the stimulus bill to push more health providers into the electronic age.

There are three items to consider, and they are the same ones we must always deal with:

Confidentiality - WHO has access to your health records? Right now hospitals, doctors, pharmaceutical companies and the government have access to your health records. And probably a lot more marketing companies have pieces of information, as well. A online pharmacy clerk in West Overshoe knows all your prescription medications and is paid minimum wage.

Integrity Is your data accurate? Or has someone stolen your medical information to get health care, died, and left you with a rolling disaster?

Availability Can you inspect and correct your data - ALL your data, including any diagnoses? What if you don’t agree with one? Can you delete it?

If you compare the answers, it looks remarkably similar to where your (and my) credit record is right now - in the hands of the data miners. All my data belong to….them.

From a regulatory perspective, the Feds are not providing any real consequences for medical data breaches, or lack of HIPAA compliance. They are waving a large carrot around, instead. Only one or two organizations have actually been fined for non-compliance, despite a large uptick in data breaches. It is left to the outraged patient to sue for damages. There are no clear statistics for medical identity theft, because the appropriate agency isn’t tracking them.

It’s one thing to get information online, another thing to get it online safely. It seems to be a pattern in every industry that data becomes electronic before any thought of security.


Dec 28 2008   3:14PM GMT

Securing the Security Devices



Posted by: Arian Eigen Heald
Compliance, Security Devices, IT audit, Hardware & InfoSec, Tools for Auditing and Security, TCM (Truly Clueless Management), Admins and Auditors, Tools & Tricks of the Trade, "How Do You Know?"

OK, so you’ve bought the glow-in-the-dark, meets all the compliance requirements and looks really shiny “security solution” from a vendor (one or many).

Or maybe your management has bought it and presented it to you as a fait accompli. (Hope I’m spelling that fancy French right!) And of course either you have to manage it (without training, “that’s too expensive, just watch the consultants put it in”), or it’s been “outsourced.”

Or as an auditor, you’ve been told to use it for all auditing functions, and not worry about doing any follow up or periodic testing because this product is such a “time-saver.”

So, how do you know (my favorite question) it’s working and doing a good job? Not what the fancy report it produces says, not what the consultant says, not what the manual says, not what the boss says. What you can actually see.

I’ve been following a discussion on the Security Focus “pen-test” mailing list about how security software has just as many issues as regular software. I don’t like thinking that the software protecting me and writing to a SQL database is using an unencrypted ODBC connection that can be captured by ARP poisoning.

So, although I am rarely asked to audit or test a firewall, IDS or host IDS, having run and learned on all of them, I have some suggestions for you to try out.

NEXT: How to Audit Your IDS/Firewall/ECM for free.


Dec 24 2008   7:14PM GMT

Getting What You Pay For…..2008



Posted by: Arian Eigen Heald
Security, HIPAA, Compliance, Database security, IT audit, Admins and Auditors, Tearing My Hair Out, SAS 70

In my travels as an auditor this year, I’ve visited 15 states and seen approximately 20 different networks, both LAN and WAN. I’ve audited hospitals, lotteries, racetracks, banks, small businesses, large online retailers, metal fabricators, telco service bureaus and health care service bureaus.

I continue to see networks that are not patched. “It might break our custom code,” is the most common excuse, followed by, “Gee, we just didn’t get around to it.”

Software coding continues to be a security disaster in the making. Developers continue to open up databases by giving too many rights to users and application IDs. I still find individual developer IDs inside production databases.

Management continues to be unwilling to invest the money in a secure architecture. In the last three years, I can count on the fingers of one hand the organizations I’ve seen that follow secure best practices. And not use all the fingers.

I still hear people try to tell me that they don’t need a firewall because they have really good routers. And then they don’t update the IOS on the routers and/or leave the default SNMP strings in place.

If you are paying for these services, and you are getting the above, there is a problem waiting to happen on your network. If you don’t know what’s going on in your databases, time to find out before another Countrywide happens in your back yard.

Have a safe holiday. And remember: who is responsible for good security? You are. I am. Let’s keep trying to do it right.


Dec 17 2008   4:46PM GMT

Nobody is “Too Small” to Get Hacked



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

It’s been an interesting week in “Breachland,” with reports of breaches in all sorts of places: eyewear companies, auto dealerships, Universities with “password-protected laptops,” Dallas City Hall, and, unfortunately, a big German Bank.

We are already statistically well past any previous year’s statistics for number of break-ins, laptop losses, backup tapes stolen, and internal employee data theft.

And yet I still see organizations that blithely ignore data on laptops, don’t monitor or encrypt their backup tapes, and have firewall rules that are like Swiss cheese.

Security costs money. Organizations struggling to meet payroll don’t have the willingness to allocate resources to address logical security issues. “It hasn’t happened here!”

It will. The big businesses make it harder (not impossible, just harder) to hack in from the Internet, but small businesses online are becoming the focus of cybercrime cartels. Especially if those businesses have a back-door connection to much bigger organizations.

Many large organizations outsource their data to third party service bureaus, marketing firms, or connect via an Extranet. If the small organization has weak security, it provides access to the back door of the larger one. Something to think about.


Nov 27 2008   2:40AM GMT

Where The Thieves Are



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

The core requirements for committing the kind of data theft that leads to identity theft are ability, motivation and opportunity.

Ability means having the skills to do the actions required. Start-up costs for data theft are low, with information readily available, computer equipment purchased, leased or rented and high profit potential. Stealing someone’s mail is free.

Thieves can spend many years honing their skills in order to capture large aggregate data for bigger money. By breaking into servers accessible from the Internet that are not configured correctly and monitored daily, thieves create a springboard for attacks into the heart of the corporate network. Further, it is not the cracker who defaces your website and announces it to his IRQ peers that you have to worry about, it’s the cracker who doesn’t want to be seen. The thief wants to be in and out of the corporate databases with the information he/she needs quickly and quietly.

Any kind of personally identifiable information or proprietary institutional information being stolen leaves a business vulnerable to legal, operational, financial and compliance risks. And if the institution’s IT systems and administrative controls are not secure, there are grounds for a successful legal case.

Motivation. Any of a number of events can provide a “reason” to steal information and sell it: a disgruntled, overworked employee seizes on information as a way to receive compensation he feels entitled to; another employee becomes desperate when medical bills overtake her. The common denominator here is that the ability to acquire money pairs itself with a reason, no matter how badly manufactured in the mind of its creator. The reason becomes compelling when there is no oversight.

If the employer does not have controls in place to monitor access to the databases of personally identifiable information, it becomes impossible to prove who did access the information, except in an indirect fashion, such as a process of elimination or admittance of guilt. What does it say about the employer to the victim if such safeguards were not in place? Lawyers point to such lack of safeguards as negligence. Just ask Countrywide how much the illegal access to their customer databases is costing them.

Respondeat superior is the legal doctrine making an employer or principal liable for the wrong of an employee or agent if the wrong was committed within the scope of the employment or agency. This doctrine has been applied to a wide variety of computer crimes, and is likely to be used in a class action suit.

Just as the negligence doctrine could be used to impose liability for inadvertently spreading a virus, an organization may be held liable under the respondeat superior doctrine for an employee’s act of stealing and selling confidential customer information if: (1) the act occurred within the employee’s scope of employment, such as providing access to customer information to its employees; and (2) the employer knew or should have known that the employee was creating copies of confidential data and disseminating the data to inappropriate parties. Did Countrywide know? Nope. The FBI had to tell them.

Some might argue that employers would not know who exactly had stolen the information if it were taken in the course of normal duties, and this is entirely accurate. However, by logging and reporting on who has had access to the information the employer can rule out suspected internal thieves and narrow the focus of investigation. Better yet, the organization will have shown due diligence and sound business practice in addressing the risk of a lack of access controls for confidential data.

Opportunity Having access to information or materiel that can be exchanged for money is the primary goal. Proving due diligence in protecting information from outside crackers and monitoring employee access are important pieces of legal protection for our companies.

Customer service and support after the fact of theft will not let business off the legal “hook” if the institutions themselves have given the thieves unmonitored access to the information. The number of class action suits against organizations that have had data breaches is rising rapidly.


Nov 25 2008   2:57PM GMT

Data Breaches and Business Liability Part I



Posted by: Arian Eigen Heald
Security, HIPAA, Compliance, Identity theft, Data Breaches, PCI DSS, IT audit

The most significant financial impact of identity theft has yet to be examined. I believe that the risks to business and other institutions now include legal, reputation, financial and compliance risks that cannot be transferred.

Victims of identity theft are looking to recoup their financial losses and punish those people or institutions that enable identity theft to happen. The average arrest rate (according to law enforcement) is under 5% of all reported cases. Thieves do not have the resources to repay their victims by the time (or if ever) they are caught. Business does. If business organizations are providing the opportunity for identity theft to occur, they will be sued. We should make it our job to see that we are not among the defendants.

According to the Identity Theft Resource Center, (An outfit that I happen to respect a lot because they are very specific about their statistics and criteria of what a “breach” actually is), As of November 11, 2008 there have been 574 breaches, with a total of 33,593,557 records exposed.

You can download the report at their site. It’s painfully interesting.
Here’s how it breaks down, keeping in mind that we’re not done with 2008 yet:

Category: Banking/Credit/Financial
Number of breaches: 66
Number of records: 17,231,057
Overall % of breaches: 11.5 (2007? 7%)
Overall % of records: 51.3% The fewest breaches, but the most loss of data. Thieves are not stupid.

Category: Business
Number of breaches: 202 The most number of breaches. We need to get much stronger here
Number of records: 5,705,628
Overall % of breaches: 35.2% (2007? 29.3%)
Overall % of records: 17%

Category: Educational
Number of breaches: 120
Number of records: 761,303
Overall % of breaches: 20% (2007? 24.7)
Overall % of records: 2.3%

Category: Government/Military
Number of breaches: 100
Number of records: 2,656,407
Overall % of breaches: 17% (2007? 24.5%)
Overall % of records: 7.9%

Category: Medical/Healthcare
Number of breaches: 86
Number of records: 7,239,162
Overall % of breaches: 15% (2007? 14.5%)
Overall % of records: 21.5%

Why do these statistics matter? Because, one way or another, every business and every person is affected.