InfoSec Triads: Security/Functionality/Ease-of-use
Following from an introduction of the C.I.A. Triangle another triangle is used to help explain the relationship between the concepts of security, functionality and ease of use. The use of a triangle is because an increase or decrease in any one of the factors will have an impact on the presence of the other two.
As an example, increasing the amount of functionality in an application will also increase the surface area that a malicious user can attack when attempting to find an exploitable weakness.
The trade-off between security and ease of use is commonly encountered in the real world, and often causes friction between users and those responsible for maintaining security. Microsoft had long been targetted by the security community for allowing everyday users to operate the system with administrative or system level permissions, which resulted in any exploit targeting a userland application was immediately given access with full rights. When Microsoft tried to limit this functionality by forcing users to specifically request elevated privilages via User Access Control (UAC) there were high number of complaints from users who weren’t happy with the extra actions required to complete tasks. As a result many instructions and guides were created to teach users how to disable the UAC functionality; increasing the ease with use and decreasing the steps needed to perform some tasks, but at the expense of disabling an improved security system.
A recent blog post discussing the security of windows operating system states, quite colorfully that:
Windows is an open cesspool to anyone developing applications. Developers can store information anywhere in the registry and store executable components anywhere in the file system – this includes overwriting existing registry entries and files. They can also write “hooks” to intercept, monitor and replace operating system calls to do fancy things. While all of this is great from a functionality standpoint, it’s also the main reason why Windows can never be secured.
Leaving the bias and hyperbole of the above, rightly or wrongly developers are able to write to the filesystem, registry and hook API calls in order to provide the functionality expected and requested by end users. From this standpoint no functional operating system will never be 100% secure, what every system and ultimately user must settle on a compromise between acceptable functionality and usability, and acceptable security.
I’d been looking for this Dilbert strip when writing the post, just came across it now, enoy: