Data Breaches

Five Myths About Compliance

Compliance: The state of conformity of a regulated party (including a corporation, institution, individual or other legal entity) with a legislative or regulatory requirement or a recognized standard.

1. If we’re compliant, that means we’re secure.

Would that this were so! Unfortunately, the letter of the law is usually far less than the spirit of the law. If Management isn’t invested in securing the entire network, they often settle for compliance with existing laws and regulations. Having a secure environment takes a lot of resources, time, and investment in infrastructure processes. Compliance is only the beginning.

2. We have {enter name of software here} so we’re compliant.

I’m sorry, but there is no such software. There’s plenty that give out some really pretty reports and provide some oversight, but that’s very different from securing an enterprise. Usually, multiple layers of software and good people are required.

3. Our vendors tell us they’re compliant, so our information is secure. If they get broken into, it won’t impact us.

Ultimately, it’s YOUR data, whether it resides on a third-party’s web site or inside your network. If they are broken into and your data is stolen, that is what the newspaper will report. Your customers will blame YOU for not monitoring the vendor more closely. You can outsource functions, but not responsibility.

4. Everybody in my organization is trustworthy.

The “fraud triangle” consists of the following elements: Incentive, opportunity and capability. Anyone can find incentive if the opportunity and capability exists. Insider attacks are far more effective than external hackers. Organizations of any size that don’t do internal monitoring are asking for trouble - they’ve provided opportunity, incentive is plentiful and often the hack takes very little capability. If people know they are being monitored, they will think twice.

5. Compliance only happens once a year.

If you have strong security controls, policies and procedures in place, your auditors won’t spend half as much time on site, the audit will not require hours and hours of extra work and you can be quite pleased with yourself at the end of the day. Isn’t it great when you give the auditors what they’re looking for and they go away? If all that stuff is working, you have a secure environment and an audit is a non-event.

Using Your IDS as a Boat Anchor

Setting up your Intrusion Detection System to send you email alerts designed by the consultants who put it in and thinking you are secure is the equivalent of wrapping a chain around the server and tossing it in when you go fishing. It will do just as much, if not more good in the lake as it will on your network.

Here are some rules to follow for using an Intrusion Detection System on your network:

1. “Set It and Forget It” makes an IDS useless.

Why? Activity is happening on the network all the time. Suspicious events happen that are based on low level alerts that can aggregate - setting your email to high alerts only means you are missing the boat. Plan to spend at least an hour a day looking at the primary console and logs after you’ve finished cruising your firewall logs. And no, using an ESM (Enterprise Security Managment) tool to alert you does not get you off the hook. Only the human mind is capable of correlating activities and events in a remotely effective manner. We don’t yet have sufficient heuristics to automate intrusion detection.

Intrusion Detection Systems have a back end database to hold all the signatures they can monitor for. Some IDSs install agents on servers and have remote sensor collectors (say for the other side of the continent). The signatures can be updated almost daily. Do you need to install all the new signatures? No, but you’d better make sure you install the newest and nastiest ones that apply to your network. And keep the servers and database patched.

2. “We get too many false positives!” means it has not been configured correctly.

Why? Intrusion Detection Systems must be tuned. That means using about a month to analyze the traffic your IDS sees and eliminate the normal flow of events from your alerts. IDSs have an enormous database of signatures and if you turn all alerts for those signatures ON, you’ll be watching for UNIX hacks on your all-Microsoft network. Remove unneeded signatures from monitoring, and little by little you will remove alerts that are really normal traffic on your network. Why a month? Some transmissions only occur once a month. And taking out those signatures gives your sensors more CPU to see the traffic.

3. “One Size Fits All” means you’re not wearing anything.

I usually ask for the individual policies for each IDS sensor. For each sensor placement on your network, you want your intrusion detection system to watch for different traffic. It’s the best way to deploy sensors sparingly (and effectively) on a network. One sensor on the core router will not be enough, unless it can hold multiple policies: one for your internal network, one for your DMZ, and one for your extranet.

Think about it. You want to be watching for web-based attacks on your DMZ, but they will mean very little on your corporate network. Those signatures can be minimized internally, unless your internal web servers are high risk. If your DMZ is accessed from the Internet, many more signatures will need to be enabled. If you have one generic policy, you’re drowning in false positives and missing the REAL nasty traffic in the flotsam. And yes, you will have to spend time tuning and updating them on a regular basis.

4. “We have an IDS!” doesn’t mean it’s working.

Have you tested your IDS to make sure it’s working? I’m ashamed to say that too many IT Auditors don’t take a good look at this, and incorporate a simple test into their audits. A well tuned IDS should report an internal user running a portscan. It damages nothing, and is one of the most frequent first steps taken by a hacker with ill intent. And make sure that management knows ahead of time, but not the engineers in charge of the IDS. See what happens, and how quickly they report it.

4. “Oh, we outsource THAT,” means your risk has gone UP when your costs went down.

Unfortunately, I have yet to see an outsourced policy configuration on an IDS that was truly effective. IDSs are time intensive, and no one knows your network like an admin ON your network. As a result, you may get some very well-formatted canned reports every month, and it is certainly better than no IDS at all, but the effectiveness of the system decreases with every step away from your network. It’s a business decision, I know.

The other risk has to do with intrusions - you can outsource the functions, but you cannot outsource the responsibility, for both fiduciary and reputation risk should a breach occur.

Just buy a real boat anchor.

There’s a BIG Difference Between Hannaford and TJMaxx

One of my readers has commented about how badly Hannaford and TJMaxx have been treated by the media and Internet commentary because of their data breaches.

From my perspective, concerning the data breaches, I can only speak as an auditor and an engineer, not having been inside either company’s network, but, like you, I can read the news and read between the lines.

And I think that Hannaford was doing a good job and TJMaxx was not. Why?

TJMaxx was not PCI compliant, and Hannaford was. Big deal, you say, we all know about compliance! It’s the “Gentleman’s C.” Absolutely. But Hannaford cared enough to make the effort, at least, and get in line with some basic good security practices.

They were NOT storing Social Security numbers, names addresses and PIN numbers. They were doing it right.

TJMaxx, on the other hand (and a bigger company, at that) was using WEP at all their stores, and wasn’t even baseline with their information storage practices. Didn’t even try to put compensating controls in place (like a firewall between the stores and the corporate network). Have they even done anything different? Nothing in the news about that.

Hannaford was out there replacing hardware in a hurry to get rid of the malware. When was the last time a company replaced hardware in all their stores? Not cheap, and an enormous effort. Maybe it was driven by reputation risk, but that’s 150% more than we know about TJMaxx’s efforts.

Hannaford was the victim of a sophisticated attack, probably (??????) from Russia, and possibly with inside help. (More on the Russians, later.) Could they have caught it? We’ll know more, I hope, and soon.

TJMaxx let a script kiddie and his pals in, because they didn’t want to upgrade their registers and hardware until they absolutely had to. The money that went to banks and fines and external auditors for the next 20 years could have covered it. Easily. They took a risk, and had a “plan” for compliance. Their acquiring bank let them do that because it was better than no plan at all.

They’ve paid the fines and settled the suits, but they’ll be an object lesson for a long time to come.

Hannaford Is NOT The Bad Guy

I live in Portland, Maine, the home base of Hannaford, a regional grocery chain. They are owned by Food Lion, headquartered in Charlotte, NC. In turn, Food Lion is owned by an international company in Belgium, Delhaize.

Just in case you were on a desert island, Hannaford reported a breach in their credit card transaction systems.

Unfortunately, they can’t give us very many details right now for a lot of reasons - but careful reading between the lines can give you a lot of information to draw your own conclusions.

First, they replaced the hardware, at all the store locations. That tells me that it was pretty bad, because if formating the hard drive was not good enough, they ditched the hardware, and that is not a cheap proposition. And they had to keep it quiet until they got all the hardware replaced, or risk being infected again.

Second, this was not an easy breach - they are saying that malware (probably a rootkit, so undetectable by AV) was installed on ALL their store servers - and that could make it a breach from an entirely different source OR an inside job.

When was the last time you could tell something was installed on your servers without Tripwire? Trying to track down when a change was made, and by who/what? Try finding that in your Event Logs from three months ago. Don’t have them? Start going through backup tapes - they are not having any fun.

Third, the malware was uploading information to a remote site in another country. The ONLY way I know to catch this is to monitor all outbound traffic through a central firewall/router. Not many organizations have started doing this yet - but I bet more will now. And what if they used encrypted traffic? You would still see it going through the firewall - but if it was being redirected, how could you identify it?

Fourth, the Feds had to keep this quiet if they were going to catch anybody - the minute it hits the news, the bad guys shut down.

In short, it’s equivalent to a robbery, not someone walking in through an unlocked door. Whoever did this had to work very hard to set it up. Very hard. Capturing streaming transaction data is not the same as cracking a WEP-enabled wireless network.

It’s true that many organizations are doing very poorly with information security, and we have gotten used to blaming bad management practices for breaches - but this is not one of them.