Policies and mechanisms
Policies are real world statements about the
protection that the system provides. These are all statements of (significantlydifferent) policies:
- Users should not be able to read each other's mail
- No student should be able to see answer keys before they are
made public
- All users should have access to all data.
The various systems in a computer system that
control access to resources are the mechanisms that are used to implement apolicy. A good security system is one with clearly stated policy objectives that
have been effectively translated into mechanisms.
The fact that data security does not stop with
computer security cannot be understated. If your computer is perfectly secure,and an employee photocopies printouts of your new chip design, don't blame the
computer security system.
Design principles
Although every security system is different, some
overriding principles make sense. Here is a list generated by Saltzer andSchroeder from their experience on MULTICS that remain valid today (these are
fun to apply to caper movies - next time you watch Mission Impossible orSneakers or War Games, try to spot the security flaws that let the intruders
work their magic):
- Public Design Surprisingly public designs tend to be more secure
than private ones. The reason is that the security community as a while reviewsthem and reports flaws that can be fixed. Even if you take pains to keep the
source code of your system secret, you should assume that attackers have accessto your code. The bad guys will share knowledge, the good guys should, too.
- Default access is no access. This holds for subsystems just like
login screens. It sounds like a platitude, but is a principle worth following atall levels. People who need a certain access will let you know about it quickly.
- Test for current authority Just because the user had the right
to perform an operation a millisecond ago doesn't mean they can do it now. Testthe authority every time so that revocation of that authority is meaningful.
- Give each entity the least privilege required for it to do its
job. This may mean creating a bunch of fine-grained privilege levels. The moreprivilege an entity possesses the more costly a mistake or misuse of that entity
is. Printer daemons that run as root can cause logins that run as root.
- Build in security from the start. Adding security later almost
never works. There are too many holes to plug, and as a practical mattersecurity is nearly impossible to add to a fundamentally insecure system.
- In order to make such a design integration, it must be simple
and capable of being applied uniformly.
- The system must be acceptable to the users. All security systems
are a compromise between security and usability. The more features a system has,the more likely opportunities there are for exploitation. Furthermore, if a
security feature is too onerous to the users, they will just invent ways tocircumvent them. These circumventions are then available for the attackers. An
unacceptable security system is automatically attacked from within.
