In order to design a system which stops people doing something they shouldn't the security has to be included in the system from the start. It is much easier to design a secure system from the bottom up than to try to add security on to an already completed design.
Operational security consists of the various policies and procedures implemented by the management of the computer installation.
The management decide what access is allowed to what entities (it may not be people). Data and users may be classified giving the users access only to specific classes of data.
Careful personnel selection and assignment of tasks is very important. Information is made available only on a "need to know" basis.
Ordinary users should not be made aware of the security measures used in the system but they should be made aware that the system has an elaborate security system.
One method is never to give full control of important information to users. Say for instance if a user has rights to change a file instead of the user being allowed to make arbitrary changes to the file, give the user access to a program which checks all changes to the file before the program, not the user, makes the changes. This is known as "threat monitoring" and the programs which do the work are known as "surveillance programs". In this way attempts to do dangerous things are monitored and the system administrator can be informed.
All methods of enforcing security are based on the idea of limiting subjects to allowable objects. The subjects (directly or indirectly users) must have someway of proving who they are to the system, so that the system can give them their legitimate access. This process of identification is commonly known as authentication.
There are several different approaches to authentication.
The artifact based methods depend on the user having some object, such as a key or a swipe card. The advantage of this system is that it is simple for the user. As long as they have their key, the system will allow them to do their work.
The biggest disadvantage is that if the object is lost or stolen, access cannot be given to the legitimate user and can easily be taken by a thief.
To get around these disadvantages is to permanently attach the artifact to the legitimate user. Well, we don't usually implant keys or cards into people, instead we look at something unique which the person already has.
Such things as voice characteristics, or finger and hand prints, and retinal patterns. These are regarded as being unique (at least to sufficiently small probability).
A similar but different approach uses behavioural characteristics of the user such as the manner in which they type, or the way the strokes are made in a signature. Supposedly we all have a distinct rhythm to our typing, different keys are followed with different gaps between them. This method can be added to password methods to increase the security.
There are still problems with such methods. The major one is that the legitimate users can frequently be rejected. The voice print may come from someone with a cold. The finger print may have a cut etc. The user may have a sore finger and has to type with the other hand.
And unfortunately the solution is also problematical. Make the system not quite so strict, relax the identification parameters. This enables the legitimate user to get access unless they have a particularly bad cold for example. Of course this means that someone else may also be able to pass for our legitimate user.
Some of the schemes do seem very good. Retinal scans claim false acceptance rates as low as 1 in 3 million (1 in a trillion if both eyes are used). There are still reasons why such reliable systems are not used. Cost is one of them. Do we really need that level of security. We can no longer access our machine from anywhere, there has to be specific terminals equipped with the retinal scan machinery. There are also other issues, privacy of the users, some people are just reluctant to use such techniques.
Of course of all security measures the simple password is the most widespread. Almost every multi-user computer system requires users to logon and type a user name and a password. Extra passwords can be required for extra privileges.
Recommendations: Any system administrator should provide "advice" on choosing and maintaining your passwords. The most important thing is that the password should not be guessable, even by your closest associates. This rules out names, birthdates, anniversaries, favourite foods, bands etc.
Since trial and error may be used by a criminal to discover your password it is usually compulsory to have a password at least 6 characters long. 8 characters is a better minimum.
Exercise: Using exhaustive testing on a 6 character password from a character set of 100 characters, how long on average would it take to crack if the password could be checked every millisecond.
Answer: 10^6 combinations / 10^3 tries per second = 10^3 seconds - on average 500 seconds, just over 8 minutes.
Since many systems store passwords in one-way encrypted files (which themselves are not protected from reading) it is not a good idea to use words which could be found in dictionaries. The security breaker can copy the password file and encrypt all the words in a dictionary looking for a match. Once a match has been found they know your password.
This leads to the recommendation that your password should contain a mixture of letters and digits or symbols. A strange mixture of upper and lowercase also helps.
Because of the different methods used by someone trying to break in to the system, the system administrator (or maybe even the system itself) will suggest (or demand) that you change your password frequently. This way even if someone manages to get hold of your password and is using your files without your knowledge they will lose access when you next change your password.
People should never give their passwords to other people. Particularly if this entails writing the password down or transmitting it via email.
Another difficulty with passwords, particularly in an institution such as a university, is giving initial passwords. If the system allows the user to change their password then the usual thing is for the system administrator to give everyone an easily remembered or generalisable password. The user is supposed to change the password as soon as they login.
Many users never do this. Some don't log in for a long time. This gives easy access for an amateur hacker. Imagine a system whereby each student had a tight limit on the amount of CPU time and disk space they can use. If someone goes through all the guessable accounts and finds those which haven't been used yet they can use that persons resource allocations (probably changing the password in the process).
Unfortunately the very policies which make your password safer make it harder for the user. If they cannot use easily remembered words they find it easier to forget their passwords. If they have to change their passwords regularly, this makes it easy to get passwords confused and forgotten.
All this conspires to make users more likely to do the forbidden things such as typing their name in backwards unless the password system actually stops them; or writing their password down somewhere, I don't know of a system that can stop someone doing this yet.
Another problem with passwords is when a people have many logins on different systems and requires passwords for them all. This tempts them to use the same password on all systems, compromising security on all of them.
Partly because passwords are such a common method of providing security, hackers have spent a lot of time trying to work out ways of breaking them.
Passwords are usually used when the user connects to the system. The login program puts the password through the encryption function and checks that the stored encrypted password is the same. If so the user is given access, if not the user is informed of some mistake in the login process and has to commence again from the beginning. If the login can be made via remote communication the login program should only give the user a small number of attempts (commonly three) before cutting off communication. Then a timer should make sure that the same user can not even attempt to login for several minutes. This makes it difficult for a hacker to try multiple passwords.
The login system should also keep a count of failed attempted logins and if the number gets suspiciously high the system administrator should be notified.
Maintaining an audit log of important events in the computer system can help discourage or find attempts to breach security. Of course any audit log must be held in a secure part of the system. For the log to work it must be regularly and carefully reviewed. An element of randomness in the timing of reviews is also important.
So far we have concentrated on methods preventing an unauthorized person having access to the computer system. What about stopping people with access to the system from having access to those things they are not allowed to?
In general what we want can be described as an access control matrix. Each column of the matrix stores the access rights over each object which the system is protecting. Each row denotes a protection domain, usually associated with someone or something (such as a program or shell script) which can act in the system.
A protection domain is basically just a set of pairs <object, access rights>. Any program running within a particular protection domain is restricted to the access rights associated with each object in its set.
An object can be anything which needs protection, memory, files, programs, devices. A subject operating within a protection domain is limited to the access provided by that domain. A domain may be associated with a program with a user or with a group of users. We will see that it is possible to change protection domains (all done in a controlled, safe manner).
Each element of the matrix shows directly what rights each protection domain gives over every object in the system.
This is what we want theoretically. We can then see the rights of each subject and we can also see which subjects have rights over each object.
The protection domains themselves can be included as objects which need protection. We can use this to change protection domains. "Switch"ing domains is not symmetric, just because D2 can switch to D3 does not automatically imply that D3 can switch to D2.
Each new object requires a new column to the matrix. The creator determines the rights. Since it is necessary to change access rights, which means making changes to the access matrix, we need to grant permission to make these changes as well. We normally indicate an "owner" which can make any possible changes to the object column it controls.
The "owner" right means that all access to that object (a column of the matrix) can be modified within that domain. Similarly we can put "control" rights in the columns of a protection domain object. This means that for example a process executing in protection domain D2 can make any changes it likes in the row for protection domain D4.
Of course a full access control matrix is not possible. The matrix would be too huge, however most of the matrix would be empty space, where empty space means that the subject has no access rights to the object.
There are two different but complementary ways of overcoming the size problem. Each subject may have some way of indicating that it has rights over the object or each object may keep a list of all the subjects which may access it (along with their allowed access).
An access control list is the non-empty information in a column of the access control matrix. Each object keeps such a list which identifies which protection domains in the system have access to it and exactly what that access is. So we store a list of pairs <Domain, Rights>.
Usually one subject in the system is regarded as the owner of the object. The owner has the rights to change the access control list, thereby granting or denying rights to other subjects.
Windows NT and VMS have access control lists.
The problems with access control lists are the time taken to check that a protection domain has the required rights to access the object as it is trying to do. Rather than checking all accesses, many systems limit the check to when the object is first accessed, such as opening a file. This creates further problems if another subject can get access to the file after it has been legitimately opened. Also the access rights cannot be revoked for a subject if it never closes the file for example.
The size of access control lists can still be a problem.
One way to overcome both the size and the speed problem is to have default access for most domains. The default access is checked first. If the required access is not there then the list can be searched.
The main problem with access control lists is that information for each protection domain is scattered throughout the system. Also every access to the object needs to be checked. We will see other ways of handling this shortly.
Another way of dealing with a large amount of information is to throw most of it away. You are all familiar with the method UNIX uses to control access to files (and hence devices and programs). Every file has a small number of bits describing whether or not the file can be read, written to (includes destruction), or executed (or passed through if it is a directory). There are only three protection domains: the owner, one group the owner is also a member of, and the rest of the world - "others". This saves on space, the number of bits is minimal. However it loses on flexibility. It becomes difficult (read that as impossible) to give a single particular person access to your files.
Question: What happens if your group has reading but not writing access to a file, and yet "others" have writing access? Do you have writing access? Go and find out