Of Bombs and bums part II

I posted a few weeks ago about the 'bum bomber' who tried to blow up a Saudi prince with an explosive hidden in his rear-end.

Well it seems at last some governments are worried about a sudden upswing in 'bum bombers' and are proposing full body scan x-rays.

One can only hope this is more media beat-up and speculation that actual plans...

Passwords!

By now it's a safe bet anyone working in the security space has heard about the leaked passwords from hotmail, yahoo and gmail.

The most interesting thing so far to come out of the leak is the results of an analysis of the passwords exposed. The results are an interesting mix and shed some light on how the message about using strong passwords is being received out there in user-land.

The most common password found was '123456' with '12346789' coming in second. It's enough to keep a security guy up at night!

Amazingly 'password' didn't make the top 20 list, but despite the fact the average password length was 8 characters, 42% of all the passwords listed were lower case only and only 36% were what we commonly consider 'strong passwords' (in complexity if not length). This shows the message is not being heard.

Why is this a concern to the security guy in the enterprise? Well the same users are likely to be in the office and these results show that the password message is not getting through. Not to mention employees with good intentions emailing work documents to themselves @hotmail so they can be diligent and work on them at home. That same hotmail address with the '123456' password....

The good news (comparitively!) is that the passwords have not been gathered due to a flaw in the security of these industry heavyweights, but by via phishing attacks against the users themselves.
The problem though is even when users are diligent and more complex passwords are used there is the problem of those same users being suckered in by phishing attacks. Even the head of the FBI was banned from online banking by his wife for almost falling victim to a phishing email.

A senior security engineer for nCircle recently presented at SecTor the results of a survey both technical and non-technical users that showed while 83% of users checked for the magic padlock in the browser when entering their credit card details, a dismal 41% checked for the same padlock when entering a password. Although the displaying the magic padlock can be easily faked.
Unsurprisingly almost 50% of users also clicked through security warnings without paying attention to them. In this we're paying the price for training end users to 'just click ok' through countless exposures to buggy software.

People can't be relied upon to pick strong passwords or read security warnings. Security guru Bruce Schneier has written about this back in 2006 when 100000 myspace accounts were exposed through a phishing attack. That wonderful password '123456' made the top 20 back then too, but the best performer was 'password1'.

Bruce comments that "We used to quip that 'password' is the most common password. Now it's 'password1.' Who said users haven't learned anything about security?"

He's completely correct and in fact I'd hazard a guess that they've continued to learn and the most common password these days (where complexity rules are applied) is 'Password1'.

What's the answer? Nothing simple comes to mind, but clearly our education of users isn't working today, we need to do better.

And finally a more humourous look at choosing a password...

Stick Figure's guide to Advanced Encryption Standard (AES).

Awesome.

So you wrote your own web server ?

Since I am posting something I can only assume I have an assignment due today, let me see... Assignment 1...28th of September... doh! Ah well, better get on with it (writing a post that is).

I am constantly amazed at the lengths developers will go to to guarantee the insecurity of the application thy are writing. The application I am evaluating at work at the moment is a web application that, up until this version, has run atop IIS. Now in all their wisdom the manufacturer has decided it would be a far better idea to write their own web server. But wait it gets better the services for this particular application need to run with local admin rights including the web server. Wait, let me get this straight you want me to expose a custom written web server with who knows how many buffer, stack and heap overflow vulnerabilities, not to mention race conditions, memory leaks et al, running as local administrator to the internet? Let me think about it. NO!

Writing a web server is hard and re-inventing the wheel is simply unnecessary. This goes for more than just web servers, encryption, authentication (another recent doozy) and authorisation schemes among others have already been built for you. If you are homebrewing something like this you are doing it wrong.

Of bombs and bums

The Register is reporting about a recent suicide bomber attempt on a Saudi Prince where the would-be assassin apparently concealed an explosive device in his *ahem* rear-end, which he then detonated upon meeting the Prince, resulting in more mess than injury (to the Prince anyway!)

I can remember flying out of Sydney not long after the infamous 'Shoe bomber' had been caught trying to destroy an airliner mid-flight. This was not long after the September 11 attacks and the already heightened airport security in place went into a new gear with the revelation that the humble shoe could be a new weapon.

I was pulled aside while going through a security check and asked to remove my shoes, which were then prodded, poked and flexed by a stern looking security guard before they were returned. No real inconvenience.

After reading the Register's article, I did give out a sigh of relief that Richard Reid hadn't tried to blow up that plane with explosives hidden elsewhere, otherwise those airport security checks could be even more painful!

What does the above have to do with information security? Not much, aside from raising awareness of the lengths to which people will go to accomplish their goals. For insiders intent on stealing data, even the most stringent security checks that may include inspecting laptops, cameras, thumbdrives and ipods would more than likely fail to find storage hidden in a pen, sunglasses, jewelry or coins.

Legal ≠ Secure

A recent discussion about the security of an application generated the response "But this was OK'd by Legal so no more needs to be done".

Legal ≠ Secure. When a Legal department is asked for input, they are purely concerned with determining whether whatever is being presented to them contravenes the law. Most of the time the law will state something along the lines of "due care must be taken not to disclose data" rather than "you must use a minimum of 128-bit encryption to encrypt the data and the transmission".

What is due care? Well that's up to the judge to decide after the lawsuit has begun. Lawyers aren't normally Information Security professionals (well none I know!) and in fact often suffer from the same mideset as most non-IT professionals in that they tend to lump all things IT into the same basket*. As far as they're concerned, if someone in IT said we've done our best to secure something, they'll assume we've done due diligence and sign off, not really making the distinction of whether the 'IT guy' (or gal!) is technical or non-technical, a programmer, sysadmin or IT security expert. It may only be later during the court case when a prosecuting expert testifies that using DES to encrypt those passwords wasn't a good idea.**

When an IT Security Professional is asked for input, they generally have a pretty good grasp of legal requirements (well the good ones will!) and can always see legal for clarification. They are the ones who can ensure from a technology standpoint that the company is obeying the letter and the spirit of the law.

You wouldn't ask an IT Professional to to organize your legal defence, so don't ask a lawyer to vet the security of your applications. While the lawyers have their part to play, in ensuring that the law is being upheld, Legal ≠ Secure.


*In fairness to lawyers, I probably lump them all into the same basket too, not really paying attention to the difference between a patent lawyer and an ambulance chaser.
**If you're a lawyer reading this and don't understand this comment, go ask a friendly IT Security Professional!

APRA IT Security Risk Guidelines

APRA have released a discussion paper and draft best practice guide on the management of IT security risks.

APRA are the Australian financial services industry regulatory body. They oversee banks, credit unions, building societies, insurance and superannuation companies.

While light on specific detail, as a quick guide on what is expected for organizations under APRA's juristiction. It's a neat, concise set of guidelines that's not too jargon heavy - ie: good for Management to give them an overview of what is considered best practice (or 'prudential practice' as APRA call it).

I quite like the recommendation that organizations need to have "an overarching IT security risk management framework, addressing matters including an IT security strategy and a hierarchy of policies, standards, guidelines & procedures; and clearly-defined security principles for this strategy, addressing issues such as defence-in-depth, control diversity, breach detection and denial of unnecessary permissions/protocols."

It's good to see a body such as APRA publishing a document like this, I think it really helps raise awareness about some of these issues that may be lagging here in Australia compared to other parts of the world. My only criticism it that it's only a 'prudential guide' and non-enforcable, but that hopefully may change in the future.

The papers are available here.

powered by Blogger | WordPress by Newwpthemes | Converted by BloggerTheme