Monday, March 31

Unfair treatment for TJX and retailers

Ben Wright left a comment on one of my postings about the Hannaford breach. He pointed to one of his blog entries titled FTC treats TJX Unfairly. Good stuff. Ben obviously understands the legal issues facing retailers much more than I do and rather than just respond to the comment, I thought it fair to put this new post up pointing to his article.

Generally, I focus on technology, so I may be guilty of haphazardly posting things about businesses like:
[Hannaford] only exposed 10% of the number of accounts that TJX did, but it's still 4.2 million accounts.
Ben got me thinking - I was implying that Hannaford is responsible for exposing (active verb) consumer information. I've already mentioned that others have done more than imply that. Even if we grant that Mark's solution would've prevented this particular case, I do see Ben's point. There is a threshold of security above which we may not want to hold retailers responsible. If a retailer is PCI-compliant and still loses consumer information, is it fair to impose massive financial implications? Does that discourage retailers from taking risks and growing their business?

Getting back to technology, Ben points to an article suggesting that the breach occurred by attackers listening in to fiber optic cable. If Hannaford was PCI-Compliant, wouldn't that transmission be encrypted? Bruce Schneier told us how to eavesdrop on fiber optic cable back in September. It sounds relatively simple. Did these attackers also break one of our commonly used encryption algorithms?

I do think it's reasonable to expect companies like TJX to disable or replace their WEP security when it becomes widely known that it's insecure. And for companies that collect credit card info to provide over-the-wire encryption. But, I don't think it's an issue for government to manage. I like that the payment card industry is trying to handle the issue amongst themselves. And if they do it right, supply and demand will result in a secure infrastructure.

Friday, March 28

One more thing for CEOs to fear

I previously mentioned the Hannaford breach and that it's the CEOs that take the fall, but now I have to add one more thing for CEOs to fear. First, it was potential impact to the bottom line or damage to the company's reputation. Then it was fines by regulators and maybe even jail time. Now, add to the list of potential repercussions of a security breach being called out in Mark MacAuley's blog. And Mark names names. He tried to convince Hannaford to put measures in place to prevent this type of attack . Now, Mark is guessing it was an inside job. The attacker installed software on every server in 300 stores. He's probably right. It's hard enough for system administrators to roll out software on that scale and effectively hit every server (even with a team of consultants). It seems unlikely for someone with no knowledge of the environment to come along and accomplish that goal -- not impossible, but unlikely given that these attacks are most likely targeted at low hanging fruit where the 80/20 rule would apply.

I hope Mark doesn't mind that I'm picking on him. There is an element of seriousness to my comment about the new item on the list of repercussions. There are a variety of convenient ways to publicly call out a CEO or other business leader for lack of movement or poor decisions. You can't hide and wait for something like this to blow over. Not any more. It's time to accept risk management as a top priority – as important as discovering new ways to expand the business. And yes, leakage of customer data should probably be high on the list of risks. No more excuses. No more walls. Lots of transparency. Viva la Clue Train!

Ira Winkler disagrees that it was likely an inside job. I'm sure he's forgotten more about hacking than I ever knew. So, he may be right. I don't doubt that someone could hit 100% of servers, but I guess I didn't see that as the goal. Maybe I'm not in tune with the motivations of hackers.

...this may be the article that Ira refers to.

Friday, March 21

The C-Level execs take the fall

One more thing re: the State Dept. passport breach. Notice who's in the news taking the heat for the breach – the CEO of the State department. That's exactly what we were told would happen at the Gartner GRC Summit a few weeks ago. It's the C-level executives that take the fall when a high profile breach occurs, which is one of the reasons why governance is vital to the business. And why a correctly done risk analysis should beget executive sponsorship for risk mitigation solutions.

It's really interesting to me that such a seemingly ordinary act has become such a high profile breach. By ordinary act, I mean seemingly non-malicious and only acting with approved rights and privileges. These employees were GIVEN the power to act. They didn't have to TAKE the power through theft or hacking. And that's the risk with privileged users. With them, it's not about security controls. They can simply decide to subvert policy. That's why Dave's post was so timely. You can audit every transaction.

Audits don’t prevent loss?

Dave Rowe, who has a fairly extensive background in both audit and IT, reminds us:
Audit’s intent is to verify the accuracy of something; typically by checking a sample of outcomes but also by making sure that critical controls are functioning.
He's making the important point that Audit should not be confused with the security controls that are designed to enforce policy. Audit is there to prove policy effectiveness. Good point Dave. Sometimes we forget the basics amidst all the marketing collateral and news articles about security, risk, compliance, and audit. Sometimes it all just feels a bit jumbled.

He then makes a simple but powerful point about the strength of automating IT audit:
Instead of sampling a few transactions and seeing if the outcome was right, you can audit every transaction to see if the outcome was right.
Yes. And that's exactly the type of technology that saved Obama's passport information. Truly effective IT audit doesn't just check that policy and controls are in place. It monitors the effectiveness of policy and controls on an on-going basis.

Obama Passport Breached by Insider

This is a great example of one of the most underestimated insider threat scenarios that I would be worried about if I were managing GRC for an organization.

Three employees of the U.S. State Department, who were properly given access rights to passport files, inappropriately used those rights to access details such as Obama's date and place of birth, e-mail address, mailing address, Social Security number, former names and travel plans. Was this a problem about not having the right policies in place? No. A problem with ineffective controls? No. It's simply a problem of a few people choosing to abuse the trust that had been given them – not out of malice, but simple curiosity (most likely).

Luckily, the State Department has computer-monitoring equipment in place that triggered alarms. And each of the three breaches was identified and dealt with. This incident will serve as a pretty strong deterrent for future curious employees who might otherwise be tempted to try the same thing. And (if this wasn't a government agency) the organization would be able to prove to auditors pretty quickly that they're effectively managing the risk associated to the access rights provided to employees and contractors. Because even when there is risk, they're watching and ready to respond.

Apparently, it was a bipartisan attack.

Tuesday, March 18

Governance of Distributed Federation Systems

I received a very interesting query a few days ago that I've been thinking about, but I don't have an answer. I wonder if any of you have the answer?

B. is concerned (and rightfully so) that nobody is thinking about audit issues related to federated IdM. He asks:
Are there any standards, or is there any organization that does audits of "federated" IdM systems. [We] are rushing into deploying a federated IdM, built around Shibboleth. I am concerned that very few institutions have done internal identity audits, and nobody is thinking about issues related to federated IdM.
Is this an area for concern? Even if the technology is solid, how do you confirm that it's implemented correctly? Are there organizations that will put a meaningful stamp of approval on individual implementations? Across organizations?

OK TJX, the spotlight is officially off of you

Or at least we'll have another name to mention in the same sentence. Hannaford Brothers - looks like you're it. Sure, you've only exposed 10% of the number of accounts that TJX did, but it's still 4.2 million accounts. An interesting point was that the account information was stolen during the card authorization process. So, it sounds like network snooping. I guess we'll find out soon enough.

Thursday, March 13

Overheard in the Cube Farm...

Do any of the techies in your company choose Pizza Over Process?

And how can a 12 oz. can of soda bring down your entire provisioning process? Find out in You Owe Me a Soda.

...and we aren't joking when we say Based on a True Story. Sad but true. Have you overheard these conversations? Got a better one?

Tuesday, March 11

What Drives Executive Sponsorship?

I had a short but interesting conversation today about what it is that drives executive sponsorship in security initiatives. Most people seem to agree that executive sponsorship is critical to any major IT initiative. At a minimum, it makes things go much smoother. I've talked to many frustrated IT managers who don't understand why the exec's can't see the need to spend money on security. And making the business case isn't easy; especially when standing in the shoes of an IT manager (where there may be limited view into business strategy). Sure, there are dozens of examples from the news about security breaches that you could point to – and some of those breaches have carried heavy financial losses ($7B at Soc Gen) – but, it's like any other area of life where you naturally think it won't happen to me. Consider the executive point of view. Why spend budget on a problem that doesn't seem likely to affect us?

So, I think the key to getting executive sponsorship is to make the risk real. And understandable. And attached to an actual loss estimate. I'm talking about IT Governance and risk analysis. If the IT manager wants to make this happen, he has to wear the hat of Risk Analyst (RA). I made up the RA title for the purpose of this discussion. It could be someone from IT, someone from an audit group, a consultant – it doesn't matter. Here are the areas that the RA needs to analyze:
  • Business assets that should be protected (information, applications)
  • The cost associated to loss of those assets (stolen data, system downtime, breach)
  • The threats and types of threats to those assets (hackers, viruses, DoS attacks)
  • The likelihood of threats actually occurring (controls in place, ease of threat)
The organizational risk then becomes a computation of costs of asset loss and threat likelihood.

Then, the RA needs to get executive sign off on the risk analysis. The executive team is ultimately responsible for organizational risk. And in most cases, IT is so embedded in the way we do business that IT risk is business risk. Once the executive team understands the types of threats, the value of assets, and the likelihood of threats actually occurring, I believe they will push downward to put controls in place that manage the organization's risk effectively. If they don't, they're not doing their jobs.

In some cases, the reality may be that additional controls aren't needed based on the risk analysis findings. In those cases, you won't likely ever get executive sponsorship on a project to implement new controls. In other cases, the executive team will approach IT managers demanding additional controls for certain assets. At least, that's the idea.

And that's what it means to align information security with business goals. When you do that, I hope that the sponsors will find you. If it sounds like a little too much to bite off, start small. You can concentrate on a single asset (like customer credit card information) and perform a risk analysis on it. Even on a single asset, you may find ways to improve the organization's risk posture. And that's what information security is all about.