We know security and usability are orthogonal - do you?

Santa's Wish List

"they are orthogonal. However with management in the picture they are inversely proportional." .... I would agree, Tom, for an ideal world too .

"The net result is that the user encounters a usability issue with their shiny new operating system, as a security component seems to be running in overdrive and actually reducing the efficiency of the user with seemingly constant interruption."

Send IT on a Sabbatical. Follow the Journey Magical Mystery Turing.Buy IT Off for a While.

"This is a critical problem as it allows a lower privileged user, who has access to operate access, the ability to take full control of the system - a problem when it comes to shared environments like web hosts." MeThinks lower privileged user is Elevated to Challenge Self Doubt. AIQuantum BetaTest of Oneself 42 FailSafe All Ways Always. A Binary Pre-Cogniscence for HyperVision ? .... on the Greenwich Veridian.

Does your new code work?

I dont know I dont have the security access to test it....

You can book £6Billion to that without writing a line of code!

Re: Decades...

Gordon, dare I say you've *woefully* understated your case?

MS documentation since NT 3.0 has made it clear that Windows programs should respect the distinction between administrators and ordinary users. Since Win95 and Win32, there has been no excuse not to include calls to the relevant APIs. Debugging under DOS-based Windows was always such a painfully shit experience that surely no-one did it after NT came out, no? So the writing has been on the wall for over a decade now.

So why do we still have so much crap software?

Firstly, most programmers are idiots. Readers of El Reg are obviously a cut above the average, but face it: most software is written by people who don't understand the connection between the 99% spam in their inbox and their own product's insistence on running as an administrator.

Secondly, if MS try to enforce the rules, the people who get hurt are the end-users (who are MS upgrade customers) and not the idiotic programmers. That means MS have very little leverage over the idiots.

*Fortunately*, we now have botnets that threaten to destroy the entire IT ecosystem unless major vendors like MS change their attitude, break thousands of crap programs, and make it painfully hard for end-users to do what they want to do. We might start to see some progress.

Yellow Brick Roads ....... AIMen @ Work, Rest and Play

"Does your new code work?

By Tom

Posted Thursday 22nd November 2007 22:05 GMT

I dont know I dont have the security access to test it....

You can book £6Billion to that without writing a line of code!"

Of Course IT works, dread naught, Tom. And thats a lot of 00s for not writing code lines. Must be for Wizardry instead......Internal Investment

Orthogonal?

In physical security we have a saying:

"Economy and Efficiency Are Not The

Sole Objectives of Security Administration".

Within reason, who cares if security and efficiency conflict? If we REALLY wanted to make things efficient, we'd eliminate passwords all together but we'd reach a point of diminishing returns where our efficiency would lead to chaos. The computer security sector needs to learn this principle better. We can only converge so far before we put all of our eggs in one vulnerable basket and we can only save employees from the harsh and cruel burden of using a secure password or following other good practices before we've gone too far.

As for the effect on developers, poor dears! Take the time to get it right before releasing it. Then there's the arrogance of too many IT managers who insist to me that their networks are secure when I know better. If you can't catch that zero day virus I send you, you'll fall to the bot DoS attack I unleash. You can kid management but you can't kid your colleagues. Every concession for economy or efficiency make us vulnerable.

Our whole society seems to be going the wrong way. We've taken so many jobs offshore for the sake of profit that soon we won't have anybody well enough paid in the US to buy the products made abroad. It's all about money. If software isn't cheap and efficient and idiot proof for employees to use no one in management will buy it so we make it "user friendly" but turn it over to thoughtless idiots to use.

Make software developers civilly liable for major court judgments for the results of their insecure software and business owners responsible for carelessness of their employees who lose my credit card data, establish national standards for how much security is enough, and we'll begin to solve this problem. Stop complaining and go change your password to something other than the last four digits of your social security number! Quit trying to sell everyone on the desirability of converging everything to one big network in the sky and take a lesson from experience--redundancy is the key even if it is less efficient or costs more. Quit thinking of your career development and think of quality workmanship at every level. If we don't tighten security whatever the cost some group of thugs will do to us what million man armies failed to do. It starts with critical infrastructure, of course but is equally important for every level of American business. Someday we could be brought to our knees by an attack on the banking system, for example. In 1975 the worst case scenario for the Federal Reserve was a fire in the check clearing center that would stop American commerce in its tracks. Closing the check clearing center for even a few hours would cause major market fluxuations and cost businesses billions in bounced check fees, etc. Today the worst case scenario is some jerk not doing his job to maintain computer security. And if you thought a fire in the check clearing center is scary, asking employees to be responsible for security because the software developer wanted to make his product easy to use is really scary.

Begin to treat computer security as the national security problem that it is and quit worrying about costing businesses money or soon you'll be enrolling in Chinese languages classes to be able to communicate with your new government leaders.

Security by trite phrasing...

Well, security is diametrically opposed to usability, one need only look at the extremes of security and usability to realise this.

Though of course, that particular phrase has lead to convoluted security being accepted where there exists security that is quite simple to work with after deployment. And has lead to security not being adopted due to fear of drops in productivity.

The phrase 'security by obscurity is no security', is another damaging phrase, which on the face of it is true, but when inspected one finds that all security is via obfuscation (encryption is obfuscation).

I am not sure if this, 'security and usability is orthogonal', will catch on, and I do not think it is a truism. But, I know what they are trying to do. They are trying to say security does not add usability problems, well it does. But, it doesn't have to infringe upon usability as much as the proportionally inverse camp think it does.

Let's take the email retrieval problem:

A simple usable solution is to connect to the system giving a password in the plain for a user account on the system.

Now this is not secure, but you will be able to pick up your email in any country in the world, using nearly any terminal. And it can be configured server side in minutes, only requiring the user to remember a password.

A secure solution is to connect to the system via TLS with a trusted third party certificate, exchange a cram-md5 or digest-md5 password, for a SASL user not connected to the system user accounts.

Now this is fairly secure, but you will have to have certificate info on the client side, your smtp will have to support TLS and digest or cram md5 password exchange, and the setup on the server side is also more complex. You probably won't be able to retrieve your mail from any terminal in the world, so your usability has dropped.

But, using this system day in day out hardly effects usability if you are connecting from the same system each time, which is configured to make the process automatic.

Under normal circumstances, and in regards to the above example, the extra effort for security diminishes day by day, with no extra effort required from the user, so yes that could be seen to be orthogonal.

But, the server now contains a few extra systems, and whilst they can be configured to be only accessible from the local host, they represent a way to escalate privilege in the system. So, has the security of the system actually been increased as much as one would initially give it credit for.

And this is the Pandora's box of security, we cannot really measure security, it is not a science. Security is an art, and it seems that we are at the whim of fate in most of what we do.

Security really requires vigilance, intuition, deep technical knowledge, early identification of vulnerability and a lot of luck. There are some really bad configurations which are more likely to lead to compromise, and there are clever (situation and time dependent) configurations that tend to reduce the chance of compromise. But there is never anything that is 100% secure. And there are no trite phrases that sum up security accurately.

Though I will give it a go:

'Pay your security people well, you don't want them to be the weak link in the chain.'

You still don't get it

>> "Why we chose to represent it that way is because many developers, users, and administrators don't see it any other way."

This is not very accurate. You still do not seem to get the root of the problem, which makes you, sadly, a part of it.

First, only idiot developers see both concepts as a dichotomy; those without the necessary experience, or inclination to design their applications correctly. And that is the _very_ reason why propagating such fallacies is so wrong and even counter-productive: anybody in a position to offer recommendations or suggestions to the developer community should aim at knocking them over the head with a clue stick, rather than telling them what they want to hear, or are used to hearing.

Second, users -- and to a lesser degree, administrators -- being significantly removed from the underlying implementation of their solutions, really _do_not_ care nor understand why usability and security should be mutually exclusive. In my experience, they want to do their jobs and the software should allow them. And moreover, they are of the mind that they should feel confident that whatever they are doing with the software will not result on their computers being infected with malicious software, or any other negative effects. And they are vocal about this: why should their activities with the software be insecure? why do they have to think about security when the software should be in control of it? and more importantly, why should the software impede their work in doing what software should do in the first place?

If more developers payed attention to their users, or at least took some time to understand the implications of the use of their applications, we wouldn't be having this discussion.

-dZ.

Wrong approach to security.

The key issue with computer security is the C language, with its lack of control over variable-bounds. The majority of exploits involve buffer-overflows of one sort or another, and while these may RESULT from programmers' coding-mistakes, the underlying CAUSE is the security-failings of the language itself.

That, and frivolous 'multimedia' gimmicks in email and Web-browsers, which provide numerous opportunities for malicious code to get itself run.

Meanwhile we have 'Cloak-and-Dagger Security' in the form of multiple useraccounts on what is actually a personal computer, hypercomplex filesystem-permissions which no-one outside of Redmond fully understands, Forced password-complexity and frequent password-changes, and now UAC. All that this does is to infuriate users. In some case it may actually make for lower security, for example forcing users to keep changing password simply results in the password being put onto a post-it. You thus have a system with zero security, whereas peviously it had some.

In many ways the Win95/98 platform offered better security. Whilst it lacked thelabyrinthine userpermissions of NT-based systems, it also offered far fewer exploits to the potential intruder.

Unsafe file types.

So why is it that an MDB file is an "unsafe file type", blocked by MS applications like Outlook, but an XLS file is not? It would seem that security still runs second to marketing. But that is no excuse for not fixing the JET vulnerability. The problem is that MS decided long ago that JET should be discarded, not fixed.

BTW, I found while testing that VBA (used in Access and Excel, but not the source of the Jet vulnerability) would correct stack corruption errors in the user code, where Open Office would crash on the same code.