Salza identifies eight design principles that goes hand
in hand with the levels of protection that we just talked about. In designing a
secure system, the first principle to adhere to is
economy of mechanisms, and by that, what is meant is
that the mechanism should be easy enough, so that
it can be verified. The mechanism should be easy enough so that it can be
verified whether it works or not, that's important, Economy of Mechanisms.
The second principle is what he calls fail safe defaults, the
idea is you want to explicitly allow access to the system
or information. The default should not be no access. The reason
for saying this is because if the default is no access then there is no way
to guarantee that, that information is protected. This
is a negative statement again. So instead of a
negative statement like that, you want to explicitly
allow access to information. That's what is a
second design principle, is in designing the system,
you make sure that the default is fail safe.
The third design principle is what he calls complete mediation. And by
that what is meant is that the security mechanism should not
take any shortcuts. For example in authentication, you want to make
sure that when somebody presents credentials
for authenticating themselves with the system,
that has to be checked completely. And what that means is that,
there should be no shortcuts to authentication. An example of a shortcut,
will be a password file that lives on storage, if it
is cached, for performance reasons, that can
be a source of secuirty violation. Because the actual password
file on the storage system may have changed, but the cached copy in memory may
not be reflecting it, and that would
result in violation of security. If the authentication
uses the cached copy instead of the persistent copy. So that's an example of why
you need complete mediation in designing a secure
system, so that's another principle that a secure
system should adhere to. The next design principle
is what is called open design, meaning that
you want to make the design completely open,
so in other words you publish the design exactly
spec it out and publish it, but protect the keys that are used by the design.
What that means is that cracking the design,
even though it is published, in order to access
the design or get any useful service out of the system, you have to present
keys. And those authentication keys should be so hard to break.
Computationally breaking the keys should become
infeasible. So that's what is meant by
open design. And what does open design principle also foster is the underlying
tenet that detection is easier than prevention. We
don't know what all attacks are possible from the bad guys. And
so it is not possible to prevent all of them. And
therefore, what we want to do is, you want to publish
the design but make breaking the protection computationally
infeasible and detect that a violation has
happened, than try to prevent it, detect
that a violation has happened, so that's the key idea behind this open design
principle. The next principle talks about separation
of privilege. You may have seen quite
often in banks, two keys may be necessary to open the vault of the bank.
And the two keys will be held by two different individuals, so that both of
them have to come together in order to open the vault. So this is the idea
behind separation of privilege. The next principle talks about,
least privilege. That is, we want to use the absolute minimum
capability that we need, in order to carry out a certain task.
So the controls in the system should be based on need to know. An example would
be, to do certain things on your computer. For instance, if you want to install
certain new pieces of software, you may be able to do that as a normal
user on your laptop, but for certain things
you may need administrative privileges. So clearly identifying
what functions you need administrative privilege
or superuser privilege, versus, what functions
you need normal privilege and ensuring that the right level of privilege is
provided or afforded. By the system to the user, is an important design
principle. And in fact, this is the origin for the idea of Firewalls,
that are common these days in organizational setups. What firewalls do is
to insure that individuals within an
organization are able access external information from
inside the corporate network only on a need basis, or information that is inside
the corporate network is allowed to get out only under authorized conditions.
So that's the, the need to know based controls, and that has become very
common these days with the prevalence of
firewalls in, in any administrative setup. Another principle
is, least common mechanism. Or in other words, if there is a mechanism that
the system wants to implement to assure
information security. At what level should that mechansim
be implemented? Should it be implemented in the
kernel? Or should it be available as a
library that is outside the kernel? Because there
are implications when something is inside the kernel,
it has access to information that is also inside the kernel. Wheres, if it is a
library sitting on top of the kernel, then
you can limit the amount of damage a malfunctioning
mechanism can do to the system as a whole. So that's the idea
behind these common mechanisms. And the last design principle that Salza
identifies is psychological acceptability. And
by that, what is meant is the mechanisms being easy
to use for the end user, so that they completely understand what they are doing.
When they are using a particular mechanism
that is provided by the system, so good
user interface is something that is extremely important
as one of the design principles in building
a secure system. Two things jump out when you look at this set of design
principles. That is lead out by Salza in
his seminal paper back in the early 70s.
The first thing that jumps out is all of these are positive statements. They are
not negative statements. I mentioned earlier saying that,
my system prevents all violations, is a negative
statement because, it is saying that my
system is bullet proof. No system is bullet
proof, and therefore all the things that are
being laid out as design principles are positive
statements and they give a way by which you can say that these
are the things that it can do. And you build enough into your design, such that
you can detect violations when they occur,
rather than trying to prevent them. Prevention is
much harder than detection. The other thing that jumps out is the fact that all
of these principles, laid out in the
early 70s, are applicable to today's systems and
these principles were crafted when computers were
not even connected to the extent that they
are today. So the two key takeaways
from these design principles are, first of all,
you want to build the system in such a way that cracking the protection boundary
is computationally infeasible. That's the first takeaway. The second
takeaway is you build the system to detect violations
rather than prevent violations. Because prevention is much harder.
Detection on the other hand, is something that is doable.