To many users, security begins and ends with anti-virus and malware protection and regular software updates. But there is much more to security, and the more you understand the reasoning behind it, the more you can make intelligent choices when applying system security measures.
To start with, anti-virus programs and software updates are what is sometimes called reactive security — that is, responses to an obvious threat. Reactive security is the best-known type of security, and can be effective, but is rarely enough in itself. Security experts generally prefer to place their trust in architectural security, i.e. configuration choices designed to keep computer system safe regardless of specific threats, such as permissions, or root accounts that are inaccessible to most users.
When people make general statements about Linux being more secure than Windows, know it or not, they are generally referring to architectural security. As a descendant of Unix, unlike Windows, Linux was designed from its earliest days as a multi-user system, which historically has meant that it is better adapted than Windows to modern computing.
That doesn’t mean, however, that all Linux installations are more secure than all Windows ones. As the shipping condition of many phones and tablets shows, it is all too easy for a Linux or Android system to be configured so that it is essentially wide open. Instead, what it means is that Linux has been easier to secure than Windows because, when you harden the system, you are working with it rather than against it, and with core parts of the system rather than add-ons.
Goals and Principle
As Dan Razzell of Starfish Systems explained to me some years ago, making a system architecturally secure requires a clear understanding of its purpose. According to the Center of Education and Research in Information Assurance and Security (CERIAS) at Purdue University, an architecturally secure system should
- include the bare minimum needed for a specific purpose.
- protect data both when it is being used and not being used.
- protect the confidentiality and integrity of data in use.
- disable all unnecessary resources.
- limit and record access to all resources in use.
The so-called Unix way — the idea that a program should be written for one task, and do it well — is basically a popularization of these goals, not just a rallying cry for tradition.
The application of these goals comes down to a handful of working principles. These principles are generally not summarized, and security experts have different names for them, but in my experience, most would agree on at least four:
- Least Astonishment: Design should follow user’s expectations so they know what they are doing and where to find features. For example, Bash Shell commands generally use the
-roption to make them recursive, and
-vto make reporting verbose, while desktop applications generally start with the File menu on the left and the Help menu on the right. Least astonishment is really just common sense, since if a feature cannot be found, it cannot be used.
- Containment of Failure: Should a system or program fail, or be compromised by an attack, the damage should be contained so that it does not crash the system or compromise the rest of the system. This is the main principle behind user accounts with limited access to the system. Because a user account cannot control core system resources and configuration files, gaining access to the account does not give an intruder control of the system.
- Defense in Depth: An architecturally secure system does not depend on a single feature for protection. Should one feature fail to protect the system, another may instead. The concept of defense in depth explains why reactive security is not enough by itself: anti-virus software, for example, can only respond to what it knows about, and an outdated set of virus definitions can make it useless. However, in a system with limited user accounts and carefully selected permissions, other features may stop what the anti-virus software fails to detect.
- Least Privilege / Least Access: Any software, hardware, or user should be allowed only to use absolutely necessary system resources — and no more. The least access, the less chance of providing an unexpected entrance for intrusions. This principle is the most widely acknowledged among experts, and applies almost everywhere. A relevant modern example is the use of encryption so that data stored in cloud storage can only be read by the owner, and not the company providing the storage.
There is also another widely recognized principle, Security Through Obscurity, which is sometimes practiced by corporations, but always denounced by security experts as ultimately ineffective. When Security Through Obscurity is applied, known bugs are kept secret so that they cannot be used by intruders. The trouble with this idea is that intruders are likely to find the bugs anyway, but no-one else will know if they do — a major consideration, since companies like Microsoft and Apple have been known to take months to patch a bug. Partly, the distrust of this principle depends on how the software is developed, because, in free and open source software, making a bug known often means that it will be patched faster.
Security Vs. Convenience
To apply these goals and principles, of course, requires detailed knowledge of the software they are applied to. However, what is given here should be enough to show that security is not just a system administrator taking sadistic pleasure in preventing you from doing what you want. Rather, done properly, security is a logical attempt to apply well-defined goals and principles to the practical effort of keeping a system safe from harm.
If security sometimes seems overly strict, or even arbitrary, the reason is that any use of a system is a potential risk. Practical security is almost always a compromise between what a user needs to do and what needs to be done to keep a system safe. Generally, that means that a perfectly secure system does not exist — or that, if it does, you cannot use it for anything practical.
Yet, despite the frequent complaints about the unrealistic demands of security, today the problem is just as likely to be the insistence on convenience. With the rise of desktop Linux and the popularity of Android, the pressure to be as easy to use as Windows is almost irresistible. As a result, there is no question that the average distribution is less secure than those of a decade ago. That is the price we pay for automounting external devices and giving new users automatic access to printers and scanners — and will continue to pay.
However, if you understand security’s goals and principles, then maybe you will be better motivated to consider the requirements of security as much as the wishes of convenience. It is perfectly possible to find a balance between security and convenience — but pinpointing the balance is more effort than most of us are used to making.