[Gnue-dev] Security assurance levels

[Stanley A. Klein]

The underlying concept of the draft security framework proposal is that
enterprises using GNUe would review their individual business policies and
legal/contractual obligations and decide what kind of security they need.
They would then select from among the various operating systems that GNUe
runs on and the various database systems that GNUe supports, review the
capabilities of those systems, select systems that can support the kind of
security that they need, and configure their installation of GNUe to
achieve the security they require.

There is a fine line between "enforcement of business logic" and
"enforcement of security policy" where the business logic reflects
implementation of business policies and compliance with legal/contractual
obligations.  To a significant extent, the issue boils down to one of the
degree to which the system provides assurance that business policies and
legal/contractual obligations are enforced.

One can define three levels of assurance.  Call them low, medium, and high.
 (From a Common Criteria viewpoint, they would roughly correspond to EAL-1,
EAL-2 or 3, and EAL-4.  The highest level of security assurance that is
commercially certifiable in the Common Criteria consortium countries is EAL-4.

I would describe any security component of GNUe as probably being low
assurance.  Multi-user operating systems are generally medium to high
assurance, and databases are somewhere in the low to medium range.  The
assurance level of a system based on GNUe can be improved by using the
database or operating system to provide all or part of the protection.  If
a user chooses to do this, they will need to select a database and/or
operating system that can provide the needed protection and configure the
system to enable the protection to be implemented.  This may constrain
their use of GNUe features and capabilities, but again, this is the user's
choice.

It is possible to protect sensitive data -- even highly sensitive data --
using low assurance systems.  This was done for many years before serious
operating system security was developed.  Techniques include requiring all
users of the system to be fully trusted (i.e., not allowing a system to be
used for purposes of different sensitivity by users with different levels
of trust), "stovepiping" the systems (i.e., providing completely separate
systems for different enterprise functions), providing strong physical
protection, and using strong encryption on any communications links or
networks.  Many enterprises still use variations on these techniques.

A low assurance system may be adequate if some or all of the following
factors apply:

1.  A low threat environment.  For example, all users are fully trusted for
all applications, the system is relatively uninteresting to outside
attackers, and the chances of a sophisticated attack are low.

2.  A low sensitivity application.  This is another factor that causes the
system to be relatively uninteresting to outside attackers.

3.  Protection by means other than the system itself.  These include
physical protection, storing sensitive data on removable devices/media that
are physically protected when not in use, strong encryption on any
communications links or networks and other similar techniques.

4.  Any legal/contractual requirement for protection capable of being
satisfied by the means provided in (3) above.

Conversely, a medium-to-high assurance system would be required when:

1.  The threat environment is higher.  For example, the system is
interesting to outside attackers, some users are not trusted for some
applications, there is a need to seriously enforce separation of user
duties/roles, and the possibility of a sophisticated attack is increased..

2.  The application has higher sensitivity.  It is interesting to both
outside attackers and malicious insiders (such as disgruntled employees,
embezzlers, and their accomplices).

3.  The system is responsible for providing much of its own protection.
This would especially apply if the system were truly an enterprise-wide
system having outside network connections.

4.  There are legal/contractual requirements that could possibly be
subjected to third party evaluation regarding their adequacy.  These could
include the potential for a customer, regulator, or auditor evaluating the
security of the system, or the possible need of proving to a court that the
system owner took "due care" in protecting certain data.

Current trends are toward increased attention to information security.
These arise from issues of critical infrastructure protection, privacy
protection, identity theft, accounting integrity, business continuity, and
due care in the protection of data affecting others.  These issues affect
enterprises of all sizes, who will need to assess their exposure and
protect their systems accordingly.

A major purpose of the draft security framework proposal is to provide
users with options for assessing their needs and guidelines for configuring
a GNUe-based system for satisfying them.


Stan Klein