Government regulations to protect consumer privacy, the threat of liability, and the need to maintain consumer good will, are pushing American businesses towards increasing Data Security. Concurrently, the need to modernize computerized services, and to reduce costs lead companies towards open systems, and Unix and Linux in particular.
Computer vendors such as IBM, HP, Red Hat, and others, face a competitive environment in which customers judge them first on the relative ease of system setup, usability, and connectivity. Only much later, do customers question vendors on system security. Default distributions are therefore consistently wide open to attacks.
A system conversion is one of these rare opportunities where almost every piece of code and configuration is considered. It is an excellent opportunity to also consider your system and data security.
External threats to data include natural disasters, power failures, accidental erasure, and damage by malicious system penetration.
The internal threats include theft by rogue employees, suppliers, and customers, or the use of credentials stolen from travelling employees or anyone with a VPN connection (such as suppliers and customers). Rapid movement towards mobile computing and Wireless communications have opened wide many doors for sophisticated thieves. Still, the greatest risks are ignorance and negligence.
During a system conversion, familiar security facilities are replaced with unknown tools and concepts, and delivery schedules often apply to more visible application functions. The transition of a conversion poses a distinct threat by temporarily rendering even the technical staff ignorant.
Systems and applications often have common security holes that abusers study diligently. Once a system has been penetrated by an external or internal abuser (a curious explorer, an opportunistic spy, or a malicious intruder), the internal security configuration is the last line of defense. Reducing data security during or as a result of a conversion, may open issues of liability.
Natural disasters and power failures affect legacy and modern systems equally, and are best addressed by similar means. Disaster Recovery plans regularly include UPS, backups, and geographic redundancy.
Computer systems have complex facilities controlling data access: Accounting facilities monitor User logins; Access Control facilities restrict Public, Group, Program, and User access, testing them against device, directory, file, and program permissions; encryption and cross-certification protect data transmission from eavesdropping; Key-strokes are sometimes recorded for edit sessions of certain files; and many applications have additional layers for securing access.
The threat of data theft in transmission is addressed by means of encryption and certificates, although correct setup of certification is a highly complex area, that requires significant expertise to be set up effectively.
The threat of system penetration is partially addressed by protection of the Physical Plant. In the interconnected communicating electronic world, some protection can be achieved by "hardening" systems (good information on this topic is available through Hardened Linux From Scratch), and some protection is provided by Fire-walls and Intrusion Detection and Prevention Systems (IDS and IPS).
The threat of misuse by trusted users, whether legitimate users or pretenders using stolen credentials, is now beginning to be addressed by innovators such as Intrusic, Inc.
Change passwords regularly, but not too often. A stolen (or accessible) password file can be "cracked" within days or weeks with the help of a computer, so some are tempted to force-change frequently. On the other hand, studies show that most people will divulge their passwords if you just ask. Conclusion: people are the weakest password security link, training them will be more effective than a frequent change schedule.
Make passwords memorable, but not obvious. One of the weakest of weak links for people, is their memory -- the more passwords we have, and the more often they change, the more we have to write them down somewhere easily accessible. So a more secure password setup relies on memorable, complex passwords, that change, but not too often. Here are a few examples using common phrases: 2do4w0rK (notice use of 3 separate digits), $afetyF!rst (notice use of special characters for letter substitution). Whatever you do, don't allow self-selection of passwords: most people select extremely insecure ones.
Enforce the rules. Periodically, let security auditors use password cracking tools to find vulnerabilities. Also, periodically do random audits of user workstations -- some users create password-entry macros to save themselves keystrokes.
Eliminate unused services. If your file server is not supposed to support AIM sessions, there is no reason for AIM to be installed, let alone be configured and enabled. The same is true for many system utilities that come bundled with Operating Systems -- if you won't have to use them, remove them. When I upgraded from a hardened FreeBSD 4.9 to FreeBSD 5.4 I had to remove over 1000 binaries from the default 5.4 distribution to harden it (and FreeBSD UNIX is a relatively secure platform).
Apply security patches. There are regular security updates to most software packages. Security-wise it is advantageous to be a version or two behind the cutting edge, and be up to date on all security patches. If you absolutely have to have the latest 99 Terabyte RAID controller, it is easier to back-fit a hardware driver to an older system, than to plug security holes opened by the rapid development of multiple bleeding edge features (some of which will never mature).
Log security events, track them, and audit. Both UNIX and Linux systems come with system-wide event logging facilities. Logging of security events combined with regular examination of these logs is essential. Also, protecting these logs from tampering is necessary, because sophisticated abusers will always do their best to cover their tracks.
Certain popular facilities, such as Network File System (NFS) and device (e.g., Printer) sharing, need extended security consideration, and limitations in their use, because these are actually communications facilities, and more regularly than not, were designed for convenience, not security.
The UNIX view of data and program access is extremely simple. A user is either the Owner, a member of the Owner's Group, or Others (the General Public). File permissions are set for each of these ownership classes, and include Write (Update), Read, and Execute permissions. Files are organized in directories (Folders), for which possible permissions are Write (Update), Read, and Search.
This simple setup has a few gotchas. The most counter-intuitive behavior
is that file Creation, Removal, and Movement are operations on the
directories in which these files are stored, so even if you cannot read
or write to a file, it doesn't mean you cannot delete it, because these
capabilities are independent of each other. To close this door of abuse,
use the feature that prevents the deletion of a non-empty directory, and
put files into two layers of folders. For example, instead of:
$ /storage/directory/myfile.dat
use
$ /storage/directory/myfile/myfile.dat
and protect the myfile directory and the myfile.dat
file similarly. That way, only a user that can modify myfile.dat can
modify the myfile directory, and the directory itself is protected from
removal by the presence of the myfile.dat file within it.
Program permissions are another tricky area. UNIX and Linux systems
support a large number of scripting languages, including sh, csh, ksh, bash,
sed, awk, perl, and many others. A shell script can be made directly
executable, by setting its execute permission. It can then, like a
binary program, get executed simply by naming it on the command line.
However, any script that is readable, is executable, because all you
need to do is pipe its contents to the appropriate interpreter.
Consider these two lines:
$ /my/path/myscript.sh
$ sh /my/path/myscript.sh
In the first line, the system will examine if you have Execute
permissions, either as the Owner, or as a member of the Owner's primary
Group, or because it is executable by anyone (Others). If you may execute
it, the command line interpreter will determine the appropriate shell to
execute, which may be another instance of itself, to execute the script.
In the second line, the system will examine if you have execute
permissions to the name Shell (sh), the answer will be yes so it will
check if you have Read permissions on the input file to the program sh,
and if so, will proceed to execute sh on that input (command text).
Conclusion: if a script is not executable by a Group or Others, it
should not be readable by them either.
Other nuances are system-specific. Many UNIX and Linux security extensions are not yet standardized. While "sticky", "suid", and "sgid" bits are common, some additional permission settings may be available on your system of choice.
Access Control Lists are a way to extend the limited data security features of UNIX and Linux. Given a file or directory, an ACL allows the introduction of additional Groups and Users as either allowed or disallowed access to it. Corporations and government agencies are hierarchical organizations, where additional access and operational rights are granted up the hierarchy. Furthermore, some access redundancy is often maintained, so that peers can cover for each other during vacations or illnesses.
The most common problem, however, is that not all implementations of ACLs are equal. As recently as HPUX 10, for example, the HP UNIX implementation was broken. As stated before, computer vendors are not often taken to task by the market on data security failures.
Specific files are sometimes guarded more heavily than others. Both UNIX and Linux systems provide applications that enable such extreme measures as Key Stroke Monitoring, Quarantined Access (chroot and "jail" environments), and others.
In one hierarchical access environment, it turned out that the legacy COBOL environment enforced modification permissions at DELETE, REWRITE, and WRITE times, while the target COBOL environment (Microfocus COBOL) enforced them at OPEN time. When such situations occur during a conversion, they challenge you to make a choice: design a robust new data security enforcement mechanism, create an ad-hoc work-around, or throw the data wide open, disregarding the corporate security policy.
Jonathan Beit-Aharon is a founding partner of J & C Migrations located in Newton, Massachusetts. He is a conversions expert, a compiler engineer, and a former member-representative on the CODASYL, ANSI, and ISO COBOL Committees.