Sister CISA CISSP


April 3, 2009  7:30 PM

When News Isn’t News



Posted by: Arian Eigen Heald
Admins and Auditors, credit card crime, Data Breaches

A client of ours was notified recently by their financial institution that some of their credit cards had been compromised by a vendor.

The rational question followed: “Which vendor?” To which the bank replied, we aren’t going to tell you in order to protect the reputation of the vendor. Given that a high percentage of vendors have had more than one security breach, why are banks protecting them? Wouldn’t you want to know which company had been broken into so that you could pay extra attention to transactions from that company?

This kind of financial behavior is what drives people to enacting regulatory requirements for notification.

“Citibank contacted my husband and told him that they would be re-issuing him a new account number because a “major merchant” had notified authorities that its secure data had been compromised. They would not release the name of the merchant, instead saying that it was “the kind of thing we would probably hear about in the news,” she writes.

Why do we have to hear about it from the news? Why are we protecting organizations that are not protecting their data? Because it would cost the vendor money, and that would impact the profits at the bank. It’s the same reason VISA doesn’t shut down big PCI violators – and it’s why we really need independent oversight.

April 1, 2009  12:45 AM

Making it Easy For Hackers



Posted by: Arian Eigen Heald
Data Breaches, information security, Security Devices

How many rules do you have in your firewall? How many rules allow access directly into your network? How many rules allow ANY/ANY?

The more rules you have in your firewall rulebase, the higher your risk of allowing attackers in. I’m not talking about opening access to your webserver in the DMZ. But the rules are not linear, which many people (including some professionals) do not understand.

Firewall rules are inherited, like Access Control Rules, so that you can end up with some unintended consequences. If the ANY/ANY rule is above the tighter rules, the ANY/ANY rule will prevail. This is exactly what happened in a rulebase I looked at not too long ago. The company was not convinced until we ran a packet capture and I could demonstrate that IP addresses from Russia AND China were banging on internal IP addresses.

Allowing ingress to your internal network using any protocol is fraught with peril. Terminal Services/RDP allowed in? Somebody will be running scripts against the Administrator ID trying to log in all the time. FTP? There are too many ways to badly configure an FTP server. That’s what a DMZ is for. So is your Outlook Web Access. If any internal server is compromised, it becomes a jumping off point into the rest of your network. This goes for printers, too, which have little miniature hard drives.

ANY/ANY rules are red flags to the auditor – they tell me someone is sloppy, and hasn’t taken the time to ascertain what ports are absolutely necessary to open. Yes, we’re all busy, but think how busy you will be cleaning up after hackers. Or, worse yet, cleaning up your resume on the unemployment line.

Have a rule labeled TEMP? Put an expiration date and a contact person in the notes. If you are run over by the turnip truck, the next engineer will have a clue as to what is going on and will offer up burnt offerings in gratitude.


March 30, 2009  3:04 AM

“Penetration Test” Terms



Posted by: Arian Eigen Heald
Penetration testing, understanding security terms

There are some really terrific pieces of software out there for running a vulnerability scan. I have a lot of respect for all of them. The vendors are working hard to find as many vulnerabilities as possible in order to protect businesses and organizations that need to find and fix those vulnerabilities so that the bad guys don’t get in. A scan is NOT a penetration test. It can be part of one. But it usually isn’t.

Software doesn’t think. It doesn’t perform social engineering. It doesn’t walk down the hall and check everybody’s desks at night until it finds the keyring labeled “server room.” It provides a lot of false positives because it doesn’t account for configurations that have compensating controls elsewhere.

PCI requirements include, for Tier 1 vendors, a quarterly scan of the Internet-facing environment. This is a great idea; kind of like the watchman making sure he rattles the door knobs. But this is a minimum requirement.Is that really all your company can do?

Scans are great for finding the “low-hanging fruit.” They save a lot of manual time and effort to that effect. But don’t let someone sell you a scan and call it a penetration test. Software can only find what you tell it to find. Anyone (literally) can run a scan. You can rest assured that the real bad guys don’t hire “anyone” to write their malware. Someone can spend enormous amounts of time attacking your network, and you can be sure that person has a fairly high skill level. Don’t you want the folks on your side to have equal, if not better, skills?

Next: Why isn’t a scan part of a penetration test?


March 28, 2009  1:45 AM

When a “Pentest” is not a Pentest



Posted by: Arian Eigen Heald
"How Do You Know?", information security

There are as many definitions of pentest and penetration testing as there are google search results. (Some 10,700,00 or so). The problem is, there doesn’t seem to be a standard definition of what constitutes penetration testing.

As a result, there are hundreds of companies promoting their version of a “pentest,” and a wide variety of prices given for the proposed “service.” If you’re looking for “a penetration test,” you can spend hours reading about it on various vendor sites. But what are you really getting? It can vary. A LOT.

A couple of years ago one of our banking clients proudly informed us that he had commissioned a “penetration test” quarterly from the same company that managed their firewall. (Yes, I smelled a rat.)
I took a look at the contract, which did, indeed, provide a “penetration test” quarterly, and examined one of their previous reports.

I recognized the format of the report – it was output from a Nessus scan (back when Nessus used to be free). So this company was testing itself with a free product and charging the bank. Nice.

It was a nice report, and the client was happy with it. He was convinced he was going the extra mile to protect his bank. (Hopefully, he’s not still doing this.) I tried to explain to him the difference between penetration testing and a vulnerability scan, but it was hard going. Especially when he had been sold on the scan being the test.

It’s embarrassing when I see my own genre out to so blatantly make a buck. Right up there with “SAS 70 certification.” Then there’s the folks that come in with a lowball bid just to build business in a market they don’t have any traction in. They make us all look bad, don’t they?

So, what is a “penetration test?” Some of it depends on who is asking. The organization that is looking to acquire one really needs to know what they need to learn from the test. There is no passing grade, unfortunately.

Next: Let’s talk terms


March 26, 2009  8:39 PM

Hijacking Your Website



Posted by: Arian Eigen Heald
Data Breaches, information security

With all the publicity going on about the Heartland breach, not much attention has been paid to what happened to CheckFree last December. The event is also much more challenging to explain to the average consumer, but it was a significant technical attack that you and I should be aware of.

And they did it without hacking into CheckFree. Simply, they redirected visitors to a faux CheckFree customer login page on a Web site in Ukraine that tried to install password-stealing software.

There’s all sorts of pharming, phishing (I’m getting a little weary of the “ph” naming convention, frankly) out there. What is important here is that the bad guys got into the Domain Registrar in order to redirect traffic. They didn’t go for breaking into domain servers; they used a legitimate admin name and password to log into Network Solutions and change the information.

So think for a moment about how you maintain your domain registration, and how important that is to your company. Over the course of five hours the bad guys captured who knows how many IDs and logins for CheckFree.

CheckFree is not just any company, it’s owned by Fiserv, and is the backend company for financial institutions that utilize billpay services.It manages between 70% and 80% of this type of financial service. So while no data was captured from CheckFree servers, the possible loss of login information is significant. Up to 160,000 users may have been impacted.

Even though the information on Network Solutions was corrected after five hours, the badguys had set up the information to last for 48 hours in the TTL (Time to Live) configuration. So unless a massive PUSH was made (and it wasn’t) DNS servers that received that information didn’t have to check back for another 48 hours.

Registrars are becoming increasingly attractive targets. At one point the IP address in the Ukraine held multiple fake sites.

It’s worth thinking about how your business might be impacted. And what kind of username and password you’re using with your Domain Registrar. How was the ID and password to Network Solutions captured? They don’t know. Can we imagine an admin’s PC getting infected?


March 26, 2009  2:16 PM

Sweet Contest this month



Posted by: Arian Eigen Heald

Check out the contest for an XBOX this month here on the IT Knowledge Exchange. It made my mouth water!


March 17, 2009  2:13 AM

The Emperor Has No Clothes



Posted by: Arian Eigen Heald
Data Breaches, PCI DSS, Start Laughing Now, Tearing My Hair Out

Visa is in a difficult position: it has said that merchants must be compliant, and the ultimate threat is to pull processing permissions from non-compliant merchants.

But if one of the merchants turns out to be a payment processor that generates huge profits for Visa, do they cut off their nose to spite their face? Evidently not. They just make them non-compliant. Sort of.

According to StorefrontBacktalk.com, Visa has declared that Heartland is no longer on the list of “PCI-compliant” vendors. Rather, Heartland is in a probationary period, with increased oversight, audits, etc.

But wait! In response to this announcement, Heartland declares that it had been compliant in 2008, is undergoing its 2009 assessment, and fully expects to be declared compliant.

(If you go to Heartland’s web site, they have quite a set of web pages on what it “means” to be PCI-compliant. The web page is entitled, “Ensuring You are PCI-Compliant.” They must take this literally, since THEY are not compliant (at least for the moment). Does anyone else besides me find this way too ironic?)

Are you confused yet? I sure am, and I’m the one who is supposed to be the auditor.

In a final expression of revisionist history, Visa is now declaring that “As of today, no compromised entity has been found to be compliant at the time of the breach.” So, temporarily, Heartland is not compliant, so no one who was compliant was…….I’m lost.

When is compliant not compliant? The message is, when Visa says it is. Or not.

PCI – Pay Cash Instead.


March 12, 2009  8:50 PM

You May Not Want to Know, But…..



Posted by: Arian Eigen Heald
Data Breaches, PCI DSS

If you are wondering if your banking institution has been affected by the Heartland breach, you can visit bankinfosecurity.com’s web page (updated daily) tracking the number of institutions announcing they have been affected by the breach.

Had your credit/debit card replaced (unsolicited by you) recently? You would be well advised to call and find out why.


March 9, 2009  11:59 PM

ATM Heists Grow in 2007 and 2008



Posted by: Arian Eigen Heald
Automatic Theft Machines, Data Breaches, PCI DSS

A story on Wired came out recently about a $9 million ripoff of RBS WorldPay. Further reading on Wired led me to articles about, variously, a cracking of an ATM network in 7-Eleven stores that linked to Citibank, iWire cash payment cards, and Direct Cash management cards.

It seems that the bad folks are cracking ATMs and cash/debit/gift cards MUCH faster than the banks and financial services people can keep up. They have gotten adept at being able to clone cards, crack PINS and break account limits in order to drain accounts quickly with a host of people making fast runs on the system. Profits range from $750,000 to, so far, $9 million.

Banks and businesses are being ever more cagey about announcing such breaches, pointing fingers at various processors and claiming they can’t talk due to “ongoing criminal investigations.” This is the claim for the heist of $9 million that happened last November. Frankly, that excuse is getting harder and harder to swallow.

As my last post noted, we are starting to see a pattern of “repeat-offenders.” Companies that are broken into more than once, and don’t seem to be able (or willing) to make changes so that breakins stop happening. Monster.com comes to mind.

Of course, as consumers, we don’t see an impact until our cards get canceled, or God forbid, our accounts get drained. But for people being issued cash cards as a form of payroll, this can have devastating consequences. If you’re living from paycard to paycard, and one paycard gets hacked, what will you do for food, gas other necessary things that week? It might take the card company a week or two to straighten things out – maybe more. What happens until then?

The rising cost of these data losses are being well documented. For now, banks and financial companies are eating the cost out of their profits, and collecting damages from each other. It’s not a pretty picture, and ATMs are a growing part of the mess.

This is liable to get worse before it gets better. Companies tend to be unwilling to spend money on securing data in the best of times; but in these worst of times, securing data is just not happening.

PCI – Pay Cash Instead.


February 26, 2009  2:33 PM

Another Big Processor Breach, But Nobody is Talking



Posted by: Arian Eigen Heald
Data Breaches, information security, PCI DSS

Word is rampant on blogs and security portals that another processor breach (in addition to Heartland) has occurred. Banks are being contacted by Visa and Mastercard, to replace credit cards as well as ATM cards.

The latest, from IdentityTheftBlog.info:

Thanks to a more recent credit union notice that Jai Vijayan of Computerworld uncovered from the Alabama Credit Union, we now know that this is not just credit cards that have been affected, but that the breach also appears to involve “long lists” of compromised ATM/debit cards. Visa and MasterCard remain mute about the source of the breach, although once the confirmation was found, Visa confirmed to Computerworld that a processior “experienced a compromise of payment card account information from its systems,” and MasterCard’s statement referred to the processor as being in the U.S.

The fact that the breach includes ATM cards is scary and disheartening. The fact that another large processor has been breached tells me Heartland and Hannaford were not anomalies – they represent the tip of the iceberg. Cybercrimminals have developed a way to capture streaming card data that’s being transmitted unencrypted on internal networks.

We need to start encrypting card data during every point in the transaction process, whether nor not it’s running across internal networks or sitting in databases.

Next, let’s start monitoring outbound transmissions on our firewalls and get more granular about firewall rules. Servers sitting in stores don’t need to be able to access the Internet. Or set up critical servers in a group and monitor ALL their outbound and inbound transmissions.

Wireless? OK, you say you don’t have them, but what’s to stop an employee from plugging one in? Rogue access point detectors should alert and shut down the port.

How about physical security? Servers installed in stores are the weakest link – I’ve found servers in closets, break rooms, and once, in the Gift Wrap department.

It’s much more expensive to retrofit that to install secure systems – but we are now paying the price.
One of my Rules of Thumb: You can pay now, or you can pay later, but if you pay later, you will always pay more.

I guess we’re paying more, don’t you?


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: