Author: Bruce Byfield
The truth is, anti-virus software, firewalls, and intrusion detection are only the surface of security. They are all reactive measures that attempt to respond to active threats, rather than proactive measures that anticipate threats and try to make them harmless. These applications have a major role to play, but are not enough in themselves.
Behind reactive security measures is the much broader field of architectural security: How to set up a secure system to prevent security breaches, how to minimize breaches if they occur, and how react to an intrusion and recover from it if it happens.
Architectural security is a subject that fills dozens of books. However, if you ignore the exact configuration techniques, you can break down architectural security into nine basic principles which are widely agreed upon by security architects. They apply whether you are programming, doing systems administration, or using desktop applications, and they apply whether you are managing a single home machine or a large network. They are not exact laws so much as methods of how you should think about security.
If you learn these basic principles, you can not only make more informed choices when installing and configuring software, but also learn more about your operating system. As a side benefit, you’ll also understand the reasoning behind claims that OpenBSD is more secure than GNU/Linux, or that both are more secure than Windows.
Set a security policy for your system and know what’s on it
Architectural security starts with a strong security policy and detailed knowledge of what is on your system. Without this first principle, you’re faced with making decisions about security unsystematically and without an understanding of what needs to be secured. This principle requires avoiding the default policies and choices of installation programs, and drilling down into the preferences and configuration files where you have more control over questions such as whether ordinary users can mount CDs and where you can choose individual packages.
It may also mean checking the default packages in a preconfigured group, and removing programs that conflict with security policy. On Debian, for example, if you select the Desktop Environment profile for your installation, you can see exactly what is installed by referring to the Packages.gz file on the install CD. This may be time-consuming, but unless you make the effort, your goal of a secure system is defeated at the start.
Actions should be verifiable
Verifiability is the ability to check that an action is carried out. It is a principle that looms large in programming, and explains why many experienced sysadmins prefer command-line tools: running shell commands provides transparency, so you know exactly what is being done in a way that you often don’t when clicking a box in an equivalent GUI tool. Take, for example, the recent problem with Sony’s anti-copying measures. While Sony’s installer told users that it was installing one component, it actually installed additional software users would be unaware of that was harmful in nature.
Reverse the principle, and it becomes a strong argument for the free and open source development model. Because source code is available, users who know the programming language can confirm that actions are the result of a particular block of code, and that no unexpected actions are carried out at the same time. Users who can’t read the code, of course, have to rely on an expert’s opinion, but the point is that the potential for verification is available.
Always give the least privilege practical
The principle of least privilege suggests that all processes, users, and programs should be given only the access to system resources that they need, and no more. If a process does not need to run as root, then it shouldn’t. If particular users don’t need to read or write to a particular partition, such as /boot, then they shouldn’t have the permissions to do so. When users require greater privileges or access, they should get it for as brief a time as possible.
Least privilege is one of the reasons why, ideally, users should be added to groups only as necessary, rather than being automatically added to a number of common ones. Similarly, while ordinary users can use the sudo command to run programs as root, they shouldn’t all be able to use it for any command. Instead, specific users should be limited to specific commands that they can run using sudo.
Least privilege is also the design philosophy behind the multiple system accounts found in operating systems like Solaris. Instead of having a single root account that gives complete access to the system, multiple system accounts divide root privileges, each with limited powers. When you use multiple system accounts, a cracker may gain one password, but still be unable to control the system fully.
Practice defense in depth
Average users often think they’re safe if their systems are behind a firewall. Often, they’re right. The trouble is, if the only security precaution on the system is a firewall, then breaching the firewall exposes the entire system. The principle of defense in depth suggests that a more secure solution is to have a variety of security features operating at a variety of different levels.
Instead of relying exclusively on a firewall, a system is more likely to remain secure if it is also set up to take full advantage of security features such as permissions, authentication, and whitelists and blacklists. Similarly, although the principle suggests that relying only on passwords is a poor strategy, adding passwords to the BIOS and the boot manager makes for greater security than simply relying on a single password at the desktop level.
In addition, security professionals utilize physical security measures to bolster system security. Server rooms, for example, should be restricted to authorized personnel only. Desktop systems should be physically secured so that they cannot be easily removed. Backups should be stored in a secure location, preferably off-site.
Auditing the system: keep (and review) system logs
To keep a system secure, you need a record of changes made to the system, either by its own utilities or by intrusion detection systems such as Snort and Tripwire. While you can keep some records of changes by hand, on Unix-like systems, logs of changes or errors are traditionally saved in /var/log by system applications. This system is not ideal, since altering logs to hide an intrusion is one of the first steps that an expert cracker makes.
However, since many attacks are by script-kiddies with little understanding of the system, a change in logs is often the first sign that a system has been compromised. Some intrusion detection programs, such as Tripwire, can automate the checking of logs and other key files.
Build to contain intrusions
The goal of containment is to minimize the consequences when a system is cracked. A system built with this principle in mind is like a ship with bulkheads. In the same way that a breach of the hull is quickly sealed off with bulkheads, a system built with containment in mind tries to limit the access of a successful cracker.
This principle is one of the main reasons for the division between root and normal user accounts used for everyday activities. In most cases, if a exploit succeeds against a non-privileged account, a cracker still doesn’t have access to the system’s configuration files or utilities. The individual user may lose files, but damage to the system as a whole is limited, unless security is reduced by a step such as adding non-privileged accounts to all available groups. On a more advanced level, containment is the principle behind using a chroot jail to run an untested or dangerous program in isolation.
By contrast, buffer overflows, which can occur because of the way languages such as C and C++ are designed, are an example of circumstances in which the principle cannot be observed. If an application is running as root, and an exploit takes advantage of a buffer overflow, then the exploit now has root privileges. That’s one reason why patching such vulnerabilities is a priority for conscientious programmers, and why it’s important to apply patches regularly.
A system is only as strong as its weakest link
This principal reinforces the need for defense-in-depth. The more defenses a system has, the less likely that the weakest one will leave it vulnerable. Since the weakest link is often users rather than the system itself, it may mean that you need to educate users about basic security practices, and check periodically that they are following them.
No matter how well-designed and implemented a security policy is, your efforts are wasted if users tape their passwords to the bottom of their keyboards or give their passwords to random interviewers on the subway.
Locking the barn door after the horse is gone is ineffective
Security measures taken after the fact leave you uncertain how secure a system is. An antivirus program may remove a worm or trojan, but you can never be sure whether the system is secure again.
From an architectural security viewpoint, the only way you can be reliably certain that your system is secure after being successfully attacked is to reinstall the BIOS, reformat the hard drive, and restore files from a backup taken before the system was compromised. Since these steps are time-consuming, and result in a system being off-line much longer than is you’d like, you are better off applying the other security principles so you won’t need to restore the system in the first place.
Practice full disclosure
When a system is successfully attacked, or is known to be vulnerable, let users know as soon as possible. This principle is best known at the level of operating system vulnerabilities, where there is often a stark contrast between the approach taken by Microsoft and the FOSS community. While Microsoft often holds off on disclosing security issues until shortly before it releases a patch, or there is an exploit in the wild, most FOSS projects disclose (and fix) vulnerabilities as soon as possible.
However, disclosure applies on the level of individual systems, as well. It allows the users of vulnerable system to take their own precautions, if only logging off the system immediately, until the vulnerability has been addressed.
Conclusions
Understanding and exercising these principles is not a guarantee that your system will not be compromised. In practice, you’ll need to balance them against the convenience of users — and that frequently means lowering the overall security of a system. However, without a knowledge of these principles, you are more likely to set this balancing point without any thought — and, if you’re like most people, in favor of convenience.
In the end, thinking about these principles can help shift the odds in security in your favor, and help you recover more efficiently from attacks. And, if nothing else, they can save you from the false sense of security that comes from thinking that reactive measures are enough.
Category:
- Security
