Our recent article about the fine line between security and usability started some very interesting discussions and active criticism, most of which was targeted at us - suggesting that security and usability do not form a one-or-the-other type relationship (or are at least far more independent than dependent on each other).
We already know that, and now you know that.
Why we chose to represent it that way is because many developers, users, and administrators don't see it any other way. To them, if you improve the security of a piece of software it generally means they believe they have given up some usability to achieve that goal, and vice versa.
While a greater understanding of secure development practices and security as a part of the design process means that more applications are being created without needing to sacrifice usability for security, many users have been conditioned into thinking that a tightening of security means reduced usability.
If you still think that is not the case, consider two recent examples that have affected both Apple and Microsoft.
In Apple's case, the way its firewall handled incoming connections to various services when "Block all incoming connections" was selected was not very well defined - leading to public criticism and complaints. While the firewall was performing an okay job, the lack of accurate information presented to the user marked an example where usability trumped security and there was a perceived problem. An update to OS X to address this issue brought security and usability into more harmony, without either having to suffer.
In Microsoft's case, the User Account Control (UAC) feature associated with Vista is a security mechanism that seeks to help protect the user and warn the user of applications and data that is trying to access system components that would otherwise require an administrator-level account.
The only problem is that decades of applications being able to run at administrator equivalent levels has resulted in a glut of software that claims to require administrator access to successfully install and operate on Windows. 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.
Even a simple Google search for "UAC Vista" brings up numerous guides and how-tos for disabling UAC, immediately after the Microsoft TechNet entry describing what UAC is. If the added security provided by the UAC wasn't causing such a usability problem, then those guides on disabling UAC would not appear so prominently (and so many of them) on a simple, generic "UAC Vista" search.
Other criticism focused on the discussed JET engine vulnerability. As far as it is concerned, differentiating between "not critical" and "critical" is something that can be a hot topic.
Some recent comments suggested the vulnerability may not be as bad as initially reported, since it is possible to use the .mdb file as a vehicle to execute other code, such as scripts or anything that might wipe out a database. This is true, but if access to JET-dependent software has been properly ACLed then it only affects the local user/what the user has access to. What has been described by cocoruder is a mechanism that does not rely upon this behaviour - instead it exploits a stack overflow to take control over the system running the JET service.
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. Normally they would have the ability to go haywire in the context of their account access, but now it offers them the ability to reach outside their account and gain system-wide access.
It would be like discovering that .vbs files could be compromised to run at SYSTEM level through a simple overflow, when it is already well known that they can contain system commands and any number of other potentially harmful directives.
That is why it is considered a critical vulnerability.
Doubters are welcome to argue their position, and all criticism is welcome. Before you do, though, consider the arguments raised above and whether they completely address what you would argue from.
This article originally appeared on Sûnnet Beskerming.
© 2007 Sûnnet Beskerming Pty. Ltd.
Sûnnet Beskerming is an independent information security firm.