Terminology Bloat - What's Wrong With the Horseless Carriage?

We all know how much the IT industry loves its terminology and especially its TLAs. So do we really need more?

Neil MacDonald's blog entry posits the idea that it might be time to retire the term firewalls. He raises a good point that with the addition of user- and content-aware technology to provide more control than the IP address/port approach of "traditional" firewalls, the Next Generation Firewall (NGFW - hey, that's a FLA!) the technology has advanced beyond what was originally envisaged from simple policy-enforcement devices. But, and this is a big but, they are still policy enforcement devices, wherever we place them in the network or, indeed, the stack.

What is wrong with retaining the original term, modified with something that describes its new functionality ("Next Generation") or specific purpose ("Web Application")?

In England, when we go to the builder's merchants to buy tiles, we specify roof tiles, wall tiles, bathroom tiles, floor tiles, patio tiles, etc. They are all tiles, we just prefix them with their intended location. In France, however, we have a different word for each type of tile (tuile, carrelage, carreau, faience, etc.) This makes life difficult for the foreigner, and much more confusing.

Whilst I am sure those of us working in the industry would just love to invent a new term for these wonderful new devices, spare a thought for the poor end-user. Enterprises may have got to grips with the terminology, for example, but the SOHO user has only just begun to understand what a firewall is all about. And we still can't decide what exactly constitutes a NGFW, for that matter, so how many new terms will we need to come up with to cover all of the feature options the vendors are scrabbling to include in their new firewall products? Hopefully not as many as there are French words for tile!

Let's not move the goalposts again. Let's stick with the horseless carriage option for just a little longer.

[UPDATE]: Neil responded in his latest blog post and makes a great point. Where functionality and, more importantly, the administration requirements are significantly different from a "traditional" firewall - as in Neil's example of the WAF - then a name change would be appropriate. The biggest problem with keeping the same term for all those different tools is, if you have a hammer in your hand, everything starts to look like a nail. My argument was simply that I would prefer to see the term NGFW adopted before AASG (Application Aware Security Gateway) - I don't think we need to ditch the term firewall just yet.

Don't Shoot The Messenger

Testing is hard.

For a while there I thought of making that the end of this blog post, but I guess I should elaborate a little. Testing is hard, whether you are a vendor looking to do QA, an independent test lab doing competitive analysis, or an end-user trying to decide which product to buy.

Good test plans are difficult to draw up, and solid methodologies are difficult to create. End-users often use independent reports to create short-lists before doing their own in-house testing or proof-of-concept projects. This is why vendors get so upset when they don't do well in such reports. This is understandable, but what the vendor does next is often a good indicator of character.

The first thing to do, of course, is to verify that problems highlighted in the report are genuine. Vendors should work with the test lab wherever possible and be prepared to do so with an open mind, not get all defensive about the fact their precious product has a flaw. If the test lab can show you time and time again (live or on video) that they owned a target host protected by your product, then you probably have an issue that needs fixing!

Secondly, dedicate some resources to fixing the problem rather than generating marketing FUD to disguise it or deflect attention away from it. Yes, this costs money, whether you do it all in house or engage the test lab to help. Don't expect someone else to fix your product for free!

Third, bask in the glory that comes with fixing a problem quickly and professionally thus leaving your customers exposed for the minimum possible time.

What you SHOULDN'T do is shoot the messenger!

I have seen three examples recently of vendors going on the attack straight away when they don't like what is in an independent report - one in the IPS area, one in Web Application Scanning, and one in AV.

In each case the vendor in question launched public attacks on the various test labs, one of which led Mike Rothman of Securosis to predict the death of product reviews. I think Mike is wrong in this dire prediction, and end-users had better hope that I'm right, because such reviews - when done well - are all that stands between the purchaser and all that vendor hype. That and a Magic Quadrant!

Of course, the vendor is entitled to put forward his point of view. It is not difficult to spot weak methodologies, and these can do more harm than good, and the only recourse a vendor has to to refute the results publicly.

But when you have been caught out, when your product has been shown to have a repeatable flaw, posting falsehoods and ad hominem attacks in an attempt to discredit the report, the methodology, and the engineers who carried out the tests is simply not professional.

The problem is, if the test lab in question DIDN'T foul up the test, you are going to look pretty stupid when they are forced to reveal more and more of the problem in order to dispel your FUD attack. And your customers are going to be upset too, as you dedicate marketing resources to hide an issue better addressed by engineering resources.

If you are a customer of a vendor who engages in these tactics, I would encourage you to make every effort to talk to whoever produced the report which upset them. Try to understand the problem, and make sure that it doesn't affect you. If it DOES affect you, see if they can help you reproduce the tests in your own environment (if it is not too dangerous to do so). At that point you can go back to your vendor with some concrete data, and you will also be in a position to verify any fixes they release for the problem in the future.

I have a series of research notes in the pipeline right now on testing: what you should know, and how to do it properly. It strikes me they are sorely needed!

Identity Theft - A True Story To Chill The Heart

It's typical that on the evening before you are about to leave on business for four days you realise your propane tank is empty (there is no mains gas in our village). And you will not be back home until Friday evening by which time it is too late for them to make a delivery before the weekend. And, oh look, the weather forecast has turned to snow by Monday. And so you face a bleak, cold weekend with neither heating nor hot water before they can replenish your gas supply on Monday. Oh joy.

What has this got to do with IAM, you might ask. Nothing at all. But it does give you some idea of my state of mind as I headed north to London to attend the fourth Gartner Identity and Access Management (IAM) Summit - not the happiest, as you can imagine.

But solace was to be found in the warmth of the welcome I received from my colleagues, most of whom I was meeting for the first time in London. And drink. But mainly the welcome...

IAM is a key area for Gartner's clients, of course, and so the agenda was packed with the best and brightest of those Gartner analysts who specialize in Letting The Good Guys In (LTGGI). As a tin-head myself, and part of a separate group in the Gartner Security, Privacy & Risk team tasked with covering technologies for Keeping The Bad Guys Out (KTBGO), I was not actually involved in any of the presentations. Instead, I got to observe my new colleagues in action, brainstorm ideas for research, try to sell them on the fact that if we kept everyone out, Good and Bad, it would make life (and security policy creation) a lot easier, and talk to some of our clients face to face for the first time.

Pretty soon I had forgotten all about propane problems as I immersed myself in IAM-enabled cloud architectures, security monitoring, role & entitlements management, fraud prevention and federated identity management. There were workshops too, many of which were fully booked almost as soon as the summit started, and a constant stream of analysts and clients to and from the one-on-one meeting rooms. Attendee numbers were good, an excellent sign in tough economic times, and everyone I spoke to seemed to be getting a lot out of the event. If you missed it - shame on you. Book early for next year!

Things ended on a light note with a true story of identity theft from writer and comedian Bennett Arron. It all started with a mail-shot from a home shopping catalogue company to an old address, which allowed the unscrupulous person now residing at that address to place an order and open an account with the home shopping company. That credit account allowed him to acquire a mobile phone or two. From there it was not too difficult to open bank accounts and obtain credit cards - all in Bennett Arron's name.

The end result was Arron, who had already given notice on rented accommodation to buy a house, failed to acquire a mortgage, couldn't rent another property, couldn't get a line of credit, burned through savings and ended up penniless and living with parents with his pregnant wife. It took him two years to clear his name, by which time property prices had tripled and he could no longer afford to buy a house anyway! No compensation was forthcoming from any of the companies who allowed a criminal to open accounts in someone else's name, though Arron did get a one-man comedy show out of the material and Channel 4 made a documentary on him. So that's OK then.

One remarkable thing that he demonstrated in the documentary was how trusting people can be when faced with official-looking situations. He donned a suit and tie and set up a stand in a local shopping mall offering people advice on the perils of identity theft. He also offered a free service to protect their most sensitive information provided they would... yes, you guessed it.... give him their most sensitive information.

In just two hours he spoke to twenty people, eighteen of whom happily handed over their name, address, date of birth, credit card numbers, expiry dates and even the 3-character CVV/CVS numbers from the signature strips. Only two people refused. Only one person thought better of it and returned to the stand.

"Hey, this isn't a scam is it?", he asked.

"Errrr.... no"

"Oh, that's OK then. Thought I'd better check though...."

True story!

And just goes to show that no matter how many firewalls and IPS you have installed, social engineering will get you every time.

As part of the documentary Arron attempted to prove how easy it would be to steal someone else's identity. He settled on then Home Secretary Kenneth Clarke, since it would need to be a high profile "theft" to get everyone's attention.

Arron applied for a duplicate birth certificate in Clarke's name, and within 3 days it arrived. Using that, he applied for a duplicate driving license from the UK Drivers & Vehicle Licensing Authority (DVLA), which took just a couple of weeks to arrive. As part of this process, the DVLA requested photographs for the license which had to be authenticated on the reverse with a statement from a trusted, non-family member that this was a true likeness of Kenneth Clarke. This Arron completed himself using a false name. Something of a root trust issue, here, I think....

Naturally, with a birth certificate and driving license Arron could have gone on to open various accounts, building up to bank accounts and credit cards. Scary stuff. One good thing came from this - it is now no longer acceptable to use a birth certificate as the sole means of ID when applying for a UK driving license. Wonder if they have plugged that photo certification loophole too?

As the summit comes to an end and I set off back to my home in France, I reflect on how identity theft would be so much more difficult to accomplish here by virtue of a few simple controls that are universal.

In France, if you want to open any sort of account, from a bank account, through mobile phone all the way down to the humble supermarket loyalty card, you need to provide one piece of photo ID (ironically, a UK driving license is permitted!) and at least one justification of current address. This needs to be something serious, like a bank statement or major utility bill (electricity bill, fixed phone line, but NOT a mobile phone bill).

We often consider these controls to be the bane of our lives here, since they add a layer of complexity to the most simple tasks, but in the light of Bennet Arron's story it makes perfect sense.

Sometimes customer satisfaction is not everything - sometimes you have to put security requirements ahead of signing up that new prospect.

Why we shouldn't write off chip-and-PIN just yet

There has been some pretty wild speculation in the last few days that the death of chip-and-PIN is inevitable, based on the creation of a man-in-the-middle attack developed by computer researchers at Cambridge University.

According to the Cambridge researchers, there are over 730 million payment smart cards in circulation worldwide using the EMV (Europay, MasterCard & Visa) protocol (2008 figures). Known to bank customers as “Chip and PIN”, it is widely used in Europe, is being introduced in Canada, and there is pressure from banks to introduce it in the USA.

Since its introduction in the UK the fraud landscape has changed significantly: lost and stolen card fraud is down, and counterfeit card fraud experienced a two year lull. Inconvenient, then, that they now claim the protocol is broken.

Apparently, the Cambridge researchers succeeded in building a man-in-the-middle device that reads a valid card and, at the appropriate point in the card verification process, sends the correct "PIN verified" code to the terminal, whether or not a valid PIN code was entered. Of course, the man-in-the-middle device needs a way to communicate with the card reader, and this is achieved by inserting a fake card into the reader which is connected to the MITM device by a bunch of wires.

So, it is is an interesting theoretical attack, to be sure. However, you would need a valid stolen card to start with (OK, not impossible) plus a backpack full of electronic gear and a fake card dangling from some wires. Obvious enough to tip off the merchant that something is afoot, do you think?

Here in France, where they have been using chip-and-PIN technology successfully for over a decade, many retailers have portable card reading terminals. They will take your card from you to insert into the reader and pass it back for you to enter your PIN. Not much opportunity to use your umbilically-challenged fake card there, then!

Even using fixed readers at the point of sale (POS), the fraudster would have to keep their hand in such an unnatural position throughout the transaction (whilst entering the PIN with their free hand) that it is beyond belief that alarms would not be raised (they would look like some weird, deformed, miniature concert pianist in action!)

In other words, even though a flaw in the EMV protocol has been discovered, to claim chip and PIN is broken is a bit harsh on the back of this. Indeed, simple physical protocol changes would be enough to foil any attempt to use this technology.

People are claiming that they have experienced fraudulent debits from their accounts via chip-and-PIN cards. The banks are denying liability because subsequent investigations show that a valid PIN number was entered. Leaving aside that it is highly unlikely that any of these fraudulent withdrawals have been made as a result of the Cambridge technology (nor is it likely any will be made in the near future) these sort of claims always make the papers.

The less-newsworthy reality is, however, that the majority of these withdrawals will be the result of careless disclosure of the PIN number (either by allowing someone an over-the-shoulder view when entering the PIN at the ATM, or by having a PIN "cheat sheet" stored in the wallet or purse) followed by theft or loss of the debit card. Human nature dictates that very few people will own up to these personal failures, and will instead blame the banks in an attempt to recover their money.

Apple iPad: Security Considerations

Now all the brouhaha surrounding the new Apple iPad has passed, let's take a more considered look at this device: world changer, or solution looking for a problem?

Many people have erroneously stated that the iPad is a product with no market because the netbook already covers that gap between smartphone and laptop perfectly adequately, and thus - as a device with a "proper keyboard", is superior to the iPad.

They are missing the point.

In his presentation, Jobs stated that in order for this new device to have a reason for being, it would have to outperform either (or both) the smartphone or the laptop in seven key areas:

Browsing

E-mail

Photos (sharing/viewing)

Video

Music

Games

eBooks

The netbook can do all of this, but does none of them better than a laptop. A netbook is, after all, just a small laptop, and exists purely because it offers a lower price point.

The iPad, however, scores at least 4 or 5 out of 7 (I am not convinced it can do either music or iPhone-type games better than the iPhone, nor e-mail better than a laptop), which is enough to give it a pretty significant potential market.

Yes it has some perceived "problems": strange screen aspect ratio; no GPS; no camera (think video conferencing, not photo taking); and, above all, no multi-tasking (that in is a REAL shame). But despite all of that, it is still the proverbial game changer.

Once you factor in the ability to use the new iWork apps to do some serious word processing, spreadsheet or presentation work, you have a serious contender for Travelling Companion of the Year for most corporate road warriors.

Let's face it, unless you are doing some serious keyboard/mouse work or need some significant screen real-estate, there is not much reason to choose a 6lb laptop over a 1.5lb iPad. And even the keyboard issue could be resolved with the addition of the keyboard dock accessory.

And herein lies the potential problem for the corporate security guys. In creating the perfect road warrior machine for the mobile workforce, Apple has created a repository for gigabytes of sensitive corporate data without any apparent way to a) secure it or b) remote-wipe it should the machine be lost or (more likely given its initial highly desirable status!) stolen.

It took some time for Apple to offer a nod to the security world with the iPhone and include the sort of features that meant at least the CSO wasn't tearing his hair out every time an employee turned up to work with one. These included both encryption and remote wipe capabilities, but no mention was made of these during the iPad launch.

The reason for that is probably that, if they work at all, they wouldn't be very effective in a device like this. The remote wipe capability, for example, relies on the iPhone being connected to a cellular network. Unfortunately, the vast majority of iPads will probably be sold with no 3G capability, thus eliminating this feature (not that removing the SIM card wouldn't have the same effect, of course!)

Does the iPad offer device-wide encryption for all user documents? There was no mention of this, and the iPhone's encryption mechanism proved fairly straightforward to bypass by anyone with a modicum of hacking knowledge anyway.

Whereas the iPhone was never likely to be used to store gigabytes of corporate data, however, the iPad is designed for just that. And the use of basic office productivity applications means that some means of quickly and easily getting the documents on and off the device is required. A quick look through the new SDK reveals that it will be achieved by making those documents available via a mountable share - a far cry from the current situation where applications and their data are sandboxed.

How well that mechanism will be protected (if at all) remains to be seen. But one thing is for sure - in the next 60 days the CSO/CISO is going to have to put some thought into how this latest creation from the boys in Cupertino is going to fit into his corporate security policy.