Privacy Surrendered

November 1st, 2009

I just finished writing an article for the ISSA Journal on privacy. During the research I came to the conclusion that there is another shoe left to drop - corporate privacy. I consider corporate privacy the aggregate of the obvious things like intellectual property and private data, but I also think that it should contain a provision for employees private information. What if some enterprising thief decides to target your organization? What will they learn about the people at your company? Will they be able to use it against an individual or will they be able to extort the entire organization? You need to know what’s out there. What’s on the facebook page of your employees? Is there anything compromising on flickr? It’s amazing what people will post about themselves!

Red Flags Rule is really Red Herring Rule

August 7th, 2009

The Red Flags Rule, an outgrowth of the Fair and Accurate Credit Transactions Act of 2003, or as I’m going to call it, the Future Assurance of Consulting Transactions Act of 2003, is another example of bureaucrats trying to solve a criminal problem with technology. FACT’s aim is to stem the tide of identity theft by forcing organizations that deal with credit information to implement a fraud detection program that will supposedly slow down and prevent identity theft incidents. So, starting in November, anyone that offers credit, such as car dealerships, utility companies, or telecom companies, must now implement a credit fraud detection program.

Will this engender warm and fuzzy feelings in the general public? It sure will! I’m feeling better already knowing that the local car dealerships will be implementing more complicated and of course, even more expensive procedures designed to ensure that someone doesn’t buy a car with my credit. That is, assuming that the car dealerships are still in business after the recession’s over.

What might these procedures look like, you might ask? Good question! At the very basic level, they will compare the address that you put on your credit application with the one that comes back in the credit report. If they don’t match, that’s what the geniuses in Congress call a “red flag.” Thanks to FACT, you will now have to find out why they don’t match.

Now, I’m thinking that nobody will use the excuse “I just bought a house” for a while so we should be good there. The other side of that coin, “my house just foreclosed” would probably be a “negative indicator” if you’re trying to buy a new car as well, so there goes that excuse. Thanks to Red Flags, bad guys will stick out like a sore thumb! OK, that was sarcastic because the bad guys are going to be armed with really good excuses and the dealerships are desperate so if you’re warm and breathing….

The bottom line here is that the Red Flag Rule creates a great opportunity for a lot of consultants to charge small businesses a lot of money they don’t have for a set of processes that really won’t be making much of a dent in the problem of identity theft. The idea being that the desired outcome of FACT is good, but the implementation is still way too fuzzy.

Watch out! Learn what is really required of you and what you need to do to protect your customers, your business, and be compliant with Red Flags. Then we might actually see the tide change.

What the hell is going on over at Apple?

July 5th, 2009

How do you release a product that has such a basic flaw in it that one of the fundamental tools that this product provides can be used to turn it into a zombie? What I’m talking about is the newest security flaw to hit the iPhone, the SMS vulnerability. (http://hothardware.com/News/iPhone-SMS-Vulnerability-Found-Getting-Patched/)

I’m amazed that something like this leaked through their system. But I guess that’s the question here: what is their system? Many people complain that Apple doesn’t listen when people complain about things. They’re too closed. I’ve had that experience myself with the wifi issue on my MacBook Pro. The MBP had unreliable connectivity to access points. The issue was documented all over the Internet. Folks had workarounds that would provide temporary relief, but nothing permanent. I could see it happening! But when I brought my computer into an Apple store they denied that there was any issue at all!

The lesson that Apple should take away from this is two-fold. First, you can’t solve a problem until you admit that you have one and second, there’s no substitute for a well designed and implemented product development process. In this case, one that takes into account the security issues. What this recent posting says is that even though Apple is one of the most improved vendors around with regard to their ability eliminate software flaws, they have a process that is still generating them!

As much as I’d like to offer a solution, the best I can say right now is be careful who you give your phone number to until this is fixed. For most of us, that cat is already out of the bag!

Maybe the answer is to get another phone?

Oh, and Apple, it wouldn’t hurt to spring for a little independent 3rd party validation of your products. It would help Apple, and it would help the folks that depend on your technology.

Why are people surprised about ongoing security breaches?

March 26th, 2009

I’ve been reading a lot of press recently about breaches and vulnerabilities. Nothing particularly new there - it happens all the time. But for some reason I am beginning to get annoyed at the now customary tone of surprise and fear. Surprise, I suppose, that the technology that we so heavily rely upon could fail us in this way, leading to fear, presumably, that any ‘new technology initiative’ is doomed to failure because computers are inherently insecure.

This annoys me mostly because the correct response is not surprise and fear. It should be anger.

There is nothing inherently insecure about a piece of technology like a PC or a server. It only becomes dangerous when it is built into an ill-conceived solution. It’s not the technology’s fault, it’s the way we use it.

So if all we need to do is use this stuff properly, why do these data disasters happen? It’s because the people in charge don’t care enough!!!

If there were a spate of bridges falling down across the country, people wouldn’t be wringing their hands an anguish wishing that the world was a better place and lamenting how hard it is to build bridges and how unsafe they are. There would be a massive effort to ensure that bridges are built properly. People who build bridges without involving a structural engineer would go to jail. But instead with IT, it seems we just throw a bunch of software developers and systems engineers at a problem and hope that some of them know something about security (and when they don’t, there’s always Wikipedia. Right?).

There was a breach earlier this week at webhostingtalk.com where the attackers found a flaw at their backup site and used that to gain access to their main site and steal all the user data. A cunning attack, sure. But nothing that couldn’t be prevented by a suitable security design and testing regime supported by robust and sufficient policy and audit. But what irks me the most about this event was the comment on their forum from one of their members: “Welcome to the Internet. There’s really no reason to make a huge issue out of this. Simply change your password(s) and move on.” This is a community of people who are responsible for running the very sites that we worry about–and here is a webmaster publicly stating that he doesn’t really care, total system compromise and data loss is not a big deal.

What we need is more outrage at these events. From users, management, owners and investors, and from regulators of all descriptions. I am fed up with hearing “We can’t afford to invest in security right now, we are barely funded for development work.” or “We could add more security but we would lose users because it would be inconvenient.”

Building a bridge that may fall down is never accepted as an option, so should it be for the security of IT products and applications.

Next time you read about a breach, please don’t be sad…BE ANGRY.

Dealing with Moxie - HTTPS under attack

March 5th, 2009

There has been considerable excitement recently in the press, and amongst some of our customers, about the recent presentation at Black Hat DC 2009 Briefings by Moxie Marlinspike on “New Techniques for Defeating SSL/TLS”.

What Moxie presents is a variety of variations on the classic man-in-the-middle (MITM) attack. Now MITM attacks have been around for a long time, and the idea of terminating the SSL connection at the MITM and leaving the connection between the victim and the MITM unprotected is well established. What Moxie has done is cunning in two ways. First he is using a lot of extra trick to avoid the user noticing that a “bad thing” is happening. More interestingly, I think, is that he focuses on launching the attack against the initial session HTTP page.

The way this works is:

  • Unwitting user visits http://www.importantwebsite.com
  • http://www.importantwebsite.com then redirects the user to https://www.importantwebsite.com either by an HTTP 302 or a form post.

Because Moxie attacks the first and unprotected step, he is able to subvert the 302 or form target and change it to www.pretty-much-anything-he-wants.com with our without SSL.

He then adds a whole bucket load of cool tricks to ensure this subterfuge goes undetected.

This has a number of important consequences.

  1. You can make the intended SSL connection as strong and well protected as you like. It doesn’t help in the slightest  because the user will never get that far.
  2. This mode of attack makes many technologies for securing web-sessions useless. One time password (OTP) mechanisms, for example, are often helpless outside of a trustworthy SSL session. With this attack the MITM will happily pass the OTP codes back and forth without anybody noticing. The OTP adds no protection at all.

So what can you do to avoid being a victim? I have a few suggestions to choose from.

Use software that is smarter than you are.

Use something that will take you to the right (https) page and only submit your credentials there. The Whitesky ID Vault (A TSC customer) and Roboform are good examples.

Client certificates.

If you use a technology that does not disclose a secret to the untrusted channel to authenticate then all is well with the world. Unfortunately the only system you browser knows to do this is client certificates, and I can’t really see a large bank issuing certs to all its customers.

Bookmarks for https:// login pages.

Many websites have now made their login pages https. Where this is the case you can bookmark them and avoid the http page entirely. As long as you never go to the site directly - you are good to go.

Unfortunately, dear user, you are the most unreliable part of the web session, so you will in time forget to always use your bookmarks. So really, for a safe web experience, you need to be looking at getting a local agent to look after your sites and credentials.

Super Bowl Cable Hack

February 1st, 2009

So, you’re watching the Super Bowl. You have a houseful of kids and friends, all watching your brand-new 60” flat screen. It’s a tight game and everyone is glued to the set. With less than 3 minutes left, Arizona scores a touchdown. Suddenly the picture changes – you’re watching a woman unzip some guy’s fly. You scramble for the remote while your guests gasp and your little girl says, ‘Daddy, is that what always happens after a touchdown?’

Great. You have a lot of explaining to do to your mother-in-law, and Tucson’s KVOA and Comcast have a lot of explaining to do to everyone paying for their signal. The cable infrastructure is complicated, it’s not that we don’t understand that. But, somewhere the cable company left a seam in their security, and someone found it. Was it an inside job? Maybe, but maybe they got hacked. If it wasn’t a hack, why porn? The guy who did it wanted to shock you, and he succeeded.

As an industry, we have a set of things that we do, and tell everyone else to do, to protect themselves. Sometimes bad things happen because those things weren’t followed. Sometimes bad things happen because our standards are inadequate or obsolete. We need to do better. We need to do a LOT better. As all of our systems become networked, a seam in one place can hurt a lot of people and a lot of other systems. No one should get porn instead of the final three minutes of the Super Bowl.

Heartland Payments Breach

January 18th, 2009

Just as we were recovering from the TJ Maxx breach, Heartland Payment Systems coughs up some 100m credit card numbers. I guess when that happens you have to tell someone, so why not while everyone is distracted, say by a presidential inauguration? The Heartland marketing machine is definitely in damage control mode.

In case you missed it, this may end up being the largest data breach to date. We haven’t been told just yet how the credit card numbers got coughed up, other than they suspect some new type of malware found on their servers. How did this happen? Were the standards flawed, or were the policies and procedures used to test adherence to those standards flawed?

PCI (the Payment Card Industry Data Security Standards) are there for a reason. Bad guys steal credit card numbers because it pays, and the credit card industry knows if all the numbers get out they have a big problem. It seems, though, given the number of breaches by companies ‘in compliance’ such as Heartland, that the mechanisms used to see if the standards are implemented properly are flawed. What’s the result? Another company coughs up a whole bunch of credit card numbers.

The pundits have pontificated at length already, and many are blaming the PCI standards or blaming vendors for creating inadequate security solutions. I think we should be looking at the mechanisms used to test those products and adherence to standards – that’s a big part of the problem that’s been overlooked. You can have great standards, but with no way to validate and verify adherence, you end up with holes and cracks that can be exploited. It doesn’t make sense to continue to use the same policies and procedures that have failed. It’s time to break out and do something different.

I have a hunch there will be a lot of unhappy people getting new credit cards in the mail. Those numbers weren’t stolen for fun, and the bad guys will use them to steal money. Victims will be demanding better from us, the industry that’s supposed to be protecting this information. So, what are we going to do about it? We already require third-party PCI audits, and those have failed to stop data breaches. The policies and procedures they use are still broken. It’s time – past time – for us to revisit how we are validating compliance.

Smog Computing, Seeing through the fog

August 14th, 2008

Every year we have a huge accident somewhere in the US because a group of morons think that they can charge through the tulle fog at 85MPH. They’re genuinely surprised to discover that not everyone is a foolish as they are. Unfortunately, this discovery is made too late and people die. Okay, that’s a pretty harsh comparison, but it’s pretty accurate when we think about what’s happening with virtualization and cloud computing.

I’ve made two presentations in the past two weeks and I’m amazed at how much people don’t know about cloud computing and how the marketing departments have once again driven the solution.

So, about smog. Smog is created when pollutants and atmospheric components combine in such a way that they create a big dirty cloud that hangs in the air like, well, a big dirty cloud. The marketing people would have you think of light, puffy, cute things when you think about cloud computing - “You’re on Cloud 9 when you use our service!”

I was amazed at the fact that the 100 or so folks that I’ve presented to in the last couple of weeks haven’t seen that. We have firewalls, IDS, IPS, AV, ASW, and a huge security industry for a reason: the Internet is just a big dirty cloud and we’re driving into it at near warp speed. Hopefully, when this crash happens the only deaths will be the careers of those that drove us there.

Google SSL certs expire

July 29th, 2008

Google reported today that their SSL certs had expired on their SMTP service. Although I guess this not a huge deal, and is more about image and user inconvenience than a real security issue, I think it does illustrate a continuing problem that the industry is well aware of.

No, not that SSL certs are hard to manage - the well established principle that relying on humans sucks.

So many of our policies and procedures rely on a carbon based life form deciding or remembering to do the right thing. In this case, I guess either:

  • somebody was supposed to make sure the certs stayed up to date
  • they were supposed to enter the existence of the cert into an automated tracking system
  • or the monitoring system failed and nobody noticed

We need to stop assuming that people will have the time and motivation to remember and do the right things to keep the policy engines running smoothly. Instead, policy needs to be driven by automation and compliance needs to become the path of least resistance for the carbon units.

We must always know our endpoints, know what and where they are and what they do. Scanning is a valuable tool here, but it needs to be augmented with other tools that will take the scan results and test that each endpoint is and stays in policy.

If your policy is that SSL certs must be kept up to date, then its not hard to automate a test to measure if each endpoint has any certs and if they are going to expire any time soon.

Your top level Security Governance Framework should mandate that the Security Program is driven by automation and every exception to that principle must be justified.

Privacy Experts Miss the Mark

July 10th, 2008

Sometimes it’s fun to listen to people speak about things that they obviously know nothing about. Yesterday I was trapped in my car and listening to NPR. I like the News Report with Jim Lehrer because they usually have very intelligent people speaking about subjects that they know a great deal about. However, today didn’t seem to be one of those occasions.

The topic of discussion was circling around Internet privacy and how there should be laws controlling what information search engine companies can collect about people. How much of our digital DNA can search engines keep?  (You can read the transcript here http://www.pbs.org/newshour/bb/media/july-dec08/webrights_07-09.html) It followed a piece on how the telecom companies had just gotten immunity for their law breaking acts of government sanctioned spying.

The entire focus of the chat between these two “experts” was the search engine companies themselves and how they are collecting all this information that can be used against consumers. At one point, someone said that it was good that the advertising was being focused so you didn’t get a lot of advertising spam! That’s when my head exploded.

The two “experts” talked about how the information being collected would only be used for the purposes of advertizing and that it wouldn’t be abused or shared. They had obviously missed the previous piece about the telecom companies getting immunity for their illegal information sharing practices. They also missed the news that Google has been ordered to turn over their search logs to Viacom. (Viacom also promised to keep them secret….)

What these folks didn’t talk about was users and how they’re responsible for much of the information that’s leaked onto the Internet. Nowhere in their talk did they say anything about cookie management or browser security. Nowhere was anonymous browsing mentioned! They didn’t even talk about how users can test their browsers for security. All they talked about was more legislation.

We need to provide some leadership and educate people about how their browsers should be configured to ensure personal security of our digital DNA before these “experts” rush off to more bad legislation. Testing is a very good thing because it tells you exactly where you stand and just how secure you are. More “experts” should be talking about it.