Compliance archives - Sister CISA CISSP

Sister CISA CISSP:

Compliance

Aug 17 2009   7:20PM GMT

Blaming the Auditor for Bad Security



Posted by: Arian Eigen Heald
Admins and Auditors, TCM (Truly Clueless Management), Data Breaches, Compliance, IT Compliance - Policies

Heartland Security has attempted to point the “Public Finger of Blame” at the hapless QSA auditor they used for PCI compliance, saying that the “QSA let us down.” So who is in charge of security, Heartland or the auditor?

Security is a corporate posture, not a pass/fail compliance test. You can pass the test and the next day change settings on the firewall that turn it into a router. Is the QSA still responsible? Nope. We don’t really know all the details of what happened at Heartland. But we do know that being compliant does not equal being secure. Never has, never will.

For a well written post excising this “Finger,” check out this article on CSO, written by Ben Rothke and Anton Chuvakin. Let’s just say that blaming the door lock when you’ve left the windows open is not a viable public relations option.

The corporate security posture should provide a mandate, from the top down, of the company’s position on information security. The power of C-level executives enforcing the mandate has to come into play. Otherwise it’s just window dressing - and open windows are no way to manage the security of your environment.

What IS the corporate policy? How effective is it? Is management promoting AND funding it? Policies that are effective also protect the information of employees. Everybody wins, even, long term, the stockholders.

Jul 24 2009   3:26PM GMT

Adventures in Auditing #3, or “Why Do you Need to See That?”



Posted by: Arian Eigen Heald
Admins and Auditors, Compliance, IT Compliance - Policies, IT Security

It always pains me when I get this question from a client’s IT staff. It usually means that auditing has never penetrated to that level, and people are used to doing pretty much what they please around the network. It usually goes with:

“This is a development shop. Those are not production servers or databases - so why are you asking to see users, patching, inventory, etc????”

These are the kinds of questions that will keep me employed as a successful penetration tester AND a digital forensics analyst. When I’m dead someone will prop me up to keep going.

A development environment is EXACTLY where a penetration tester goes first for exactly this reason. When you don’t know what’s running on your network, you don’t know who is on your network.

If it’s on your network, the company is responsible. Legally responsible. And that question will not hold up in court.

It’s a great version of the “sniff test:” Imagine saying it on the witness stand to a judge.


Jul 22 2009   3:09PM GMT

Adventures in Auditing #2



Posted by: Arian Eigen Heald
Physical Security, Compliance, data security

While doing a PCI exam not long ago, I visited a company that was very proud of it’s security measures, and rightly so. They had done a lot of work to secure their environment.

Sometimes it’s the smallest things that we are so used to seeing that we stop “seeing” them. They become part of the background noise of everyday functions and escape our notice. Social engineers are masters of acquiring those functions and using them for the wrong reasons. For example, the building cleaners. Do they have keys to everything in order to clean your offices? What if they decide to clean out your data?

Corporate espionage agents have been known to offer cleaners $50.00 per bag of trash. Another point of easy cash is backup tapes.

When we walked into the tape storage room, I inquired, “Do you have an inventory of the tapes in this room? How often do you check that the inventory is all accounted for?” Nonplussed, the CIO replied that the door was secured and only he and one other IT person had the key, which was signed out in the Data Center whenever it was used. So they weren’t “bothering” to inventory the tapes in the room.

Looking down, I noticed that the wastebasket was empty, with a fresh plastic bag neatly wrapped around it. I said, “Do your cleaners have a key to this room?” “Why, yes,” the CIO replied blankly. Then comprehension dawned on his face.

Next day, a new policy was posted by the tape storage door: all trash receptacles were to be placed outside the door. The CIO informed me that the lock had been changed to the door, and inventories would be done monthly.

There are some companies that go the extra mile of encrypting tapes or requiring that their cleaning companies be bonded AND employees have an annual background check.

It’s expensive, but so is losing the company’s reputation to a building cleaner……


Jul 13 2009   5:27PM GMT

Adventures in Auditing #1



Posted by: Arian Eigen Heald
Compliance, Wireless, Admins and Auditors, Adventures in Auditing

I’m still amazed that folks are going about their business believing that bad things won’t happen. Is it human nature? I thought I’d share with you some of my latest adventures in traveling about and auditing various companies. Just when I think it’s strange, it get stranger.

I was doing an audit and I routinely check for wireless connections. The manager had assured me that their policy was: no wireless. OK, but I check anyway. It’s the nature of my work: controls should be in place and they should be working. Essentially a very simple rule.

Behold, a Linksys wireless router popped up with an obvious default configuration. I followed my trusty wireless signal scanner downstairs through several departments until I came upon it sitting out in the open near a group of desks.

I headed back upstairs and asked the manager about it. His face flushed, and he said, “Where is it?” He followed me downstairs, I pointed out the router, and he reached over and yanked the network cable right out of the wall, looked around, and said, “Who plugged this in?” When no one responded, he took the casing off and stomped on it. A silence ensued.

He was peeved. Glad it wasn’t my router. Not because of the router, mind you, but the person who owned it was obviously going to have a discussion with this manager before long.

Back upstairs, his dignity somewhat restored, the manager asked about my wireless signal scanner, and I promptly demonstrated its virtues (electronics can be soothing). Canary makes a great one that scans for b/g and n networks, giving me the type of encryption AND the SSID so that I don’t have to even open my laptop. It has a visual meter so I can home in on the source of the signal and actually find the access point without my laptop (which is rather obvious).

I was ready to give it to him in hopes of escaping any further compliance corrections, but he seemed calmer at that point and thought getting one of his own was a smashingly good idea. (Sorry, I couldn’t resist).


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.