data security

In most institutional computing environments, access to program and data files is restricted to authorized persons. There are several mechanisms for restricting file access in a multiuser or networked system.

User Status

Because of their differing responsibilities, users are often given differing restrictions on access. For example, there might be status levels ranging from root to administrator to “ordinary.” A user with root status on a UNIX system is able to access any file or resource. Any program run by such a user inherits that status, and thus can access any resource. Generally, only the user(s) with ultimate responsibility for the technical functioning of the system should be given such access, because commands used by root users have the potential to wipe out all data on the system. A person with administrator status may be able to access the files of other users and to access certain system files (in order to change configurations), but will not be able to access certain core system files. Ordinary users typically have access only to the files they create themselves and to files designated as “public” by other users.

File Permissions

Files themselves can have permission status. In UNIX, there are separate statuses for the user, any group to which the user belongs, and “others.” There are also three different activities that can be allowed or disallowed: reading, writ-ing, and executing. For example, if a file’s permissions are the user can read or write the file or (if it is a directory or program), execute it. Members of the same group can read or write, but not execute, while others can only read the file without being able to change it in any way. Operating sys-tems such as Windows NT use a somewhat different struc-ture and terminology, but also provide for varying user status and access to objects.

Record-level Security

Security on the basis of whole directories or even files may be too “coarse” for many applications. In a particular data-base file, different users may be given access to different data fields. For example, a clerk may have read-only access to an employee’s basic identification information, but not to the results of performance evaluations. An administra-tor may have both read and write access to the latter. Using some combination of database management and operating system level capabilities, the system will maintain lists of user accounts together with the objects (such as record types or fields) they can access, and the types of access (read only or read/write) that are permitted. Rather than assigning access capabilities separately for each user, they may be defined for a group of similar users, and then indi-vidual users can be assigned to the group.

Other Security Measures

Security is also important at the program level. Because a badly written (or malicious) program might destroy impor-tant data or system files, most modern operating systems restrict programs in a number of ways. Generally, each pro-gram is allowed to access only such memory as it allocates itself, and is not able to change data in memory belonging to other running programs. Access to hardware devices can also be restricted: an operating system component may have the ability to access the innermost core of the operating sys-tem (where drivers interact directly with devices), while an ordinary applications program may be able to access devices only through facilities provided by the operating system.

There are a number of techniques that unauthorized intruders can use to try to compromise operating systems (see computer crime and security). Access capabilities that are tied to user status are vulnerable if the user can get the login ID and password for the account. If the account has a high (administrator or root) status, then the intruder may be able to give viruses, Trojan horses, or other mali-cious programs the status they need in order to be able to penetrate the defenses of the operating system (see also computer virus).

Files that have intrinsically sensitive or valuable data are often further protected by encoding them (see encryp-tion). Encryption means that even intruders who gain read access to the file will need either to crack the encryption (very difficult without considerable time and computer resources) or somehow obtain the key. Encryption does not prevent the deletion or copying of a file, however, just the understanding of its contents.

The dispersal of valuable or sensitive data (such as cus-tomers’ social security numbers) across expanding networks increases the risk of “data breaches” where the privacy, financial security, and even identity of thousands of peo-ple are compromised (see also identity theft). In recent years, for example, there have been numerous cases where laptop computers containing thousands of sensitive records have been stolen from universities, financial institutions, or government agencies—in such cases there is often no way to know whether the thief will actually access the data. (Often affected individuals are notified that they may be at risk, and such prophylactic measures as credit monitor-ing are provided.) In response to public anxiety there has been pressure for federal or state legislation that would make companies responsible for breaches of their data and specify compensation or other recourse for affected custom-ers. (Opponents of such laws cite government reports that find that most data breaches do not lead to identity theft, and that the regulations would increase the cost of millions of daily transactions.)

There is a continuing tradeoff between security and ease of use. From the security standpoint, it might be assumed that the more barriers or checkpoints that can be set up for verifying authorization, the safer the system will be. However, as security systems become more complex, it becomes more difficult to ensure that authorized users are not unduly inconvenienced. If users are sufficiently frus-trated, they will be tempted to try to bypass security, such as by sharing IDs and passwords or making files they create “public.”