(fwd) Re: Security framework issues

[Stanley A. Klein]

This is the other of the two messages on this thread that we forgot to cc:
to the list.  I'm forwarding it so we can document the discussions.


Stan Klein



>Date: Fri, 22 Nov 2002 17:59:23
>To: Reinhard Mueller <address@hidden>
>From: "Stanley A. Klein" <address@hidden>
>Subject: Re: Security framework issues

>
>Reinhard -
>
>Just a few comments interspersed.
>
>
>At 03:26 PM 11/22/2002 +0100, you wrote:
>>Stan,
>>
>>Am Mit, 2002-11-20 um 22.50 schrieb Stanley A. Klein:
>>> A.  I don't claim to know that much about appserver or the concept of
>>> application servers.  Every time I read or hear about application servers,
>>> they seem to be different things to different people.  Everyone seems to
>>> use the same buzzwords to mean different things that they seem to assume
>>> everyone else defines exactly as they do (and therefore they have no need
>>> to explain what they mean). 
>>
>>You may find this funny or not, but I share this experience :-)
>
>ROTFLOL
>
>>
>>My problem is that I'm expected to actually help design an appserver...
>>
>>Anyway, we've sorted out a lot of things in our meeting.
>>
>>> B.  My own view of appserver is that clients connect to appserver, and
>>> appserver connects to wherever the data is, shielding the clients from the
>>> details and complexity of the data locations and databases or other
formats
>>> in which the data is stored.
>>
>>Yes. That's part of appserver's job. The other important part is the
>>enforcement of all kinds of "business logic".
>>
>
>Hmmm.  That's an interesting way to describe it.  We run into
security-related issues when business logic begins to look like either
security policy or accounting integrity requirements.  Then "enforcing"
business logic becomes an enforcement issue, also sometimes known as a
security issue.  :-)
>
>
>>> C.  Security needs to be built-in from the start.  Adding security
later is
>>> very difficult and less likely to succeed.  The trend is toward security
>>> certification under standards such as the Common Criteria (ISO IS-15408).
>>> There was a recent announcement that Windows 2000 had been certified under
>>> the Common Criteria at Evaluation Assurance Level (EAL) 4 (which is the
>>> highest level in the US for non-government certification).  I have also
>>> seen a comment that the certification conditions are very restrictive,
such
>>> as no network connection allowed.
>>> 
>>> Tony Stanco at George Washington University has a project to security
>>> certify Security Enhanced Linux, which will be a loadable module of the
>>> Linux 2.6 kernel.  This will be a pilot project for certifying the
security
>>> evaluation of a free/open-source software project.  He is working with the
>>> people at NIST and NSA, which are the US representatives on the
>>> international consortium of information security agencies that developed
>>> the Common Criteria.  Under the rules of the consortium, certification in
>>> any one country is valid for all the others.  It is my understanding that
>>> they will try to achieve EAL-2 within about a year and EAL-4 within a few
>>> years.  Part of the Common Criteria evaluation considers the development
>>> methods, which will need to be carefully interpreted for use on
>>> free/open-source projects. 
>>> 
>>> If someone were to express interest in the security of GNUe, it would be
>>> much easier to show that it is possible to provide security by installing
>>> and using Security Enhanced Linux (or some other certified operating
>>> system) to protect the appropriate GNUe files than to claim that GNUe
>>> provides its own security using its own code.
>>
>>From my point of view, security is not a "function" of a program, it is
>>something that has to go all through the code. In that respect, I regard
>>security much like quality or stability.
>>
>>However, some special aspects, for example authentification, are handled
>>by specific code and in this fields we can (should) reuse functions that
>>are already there, in our example we could base the authentification
>>mechanism on PAM.
>
>Some aspects of security are functional.  Other aspects are indeed
elements of quality.  Some people use the term "information assurance" to
describe security, and that reflects your viewpoint of viewing security
like quality and stability.
>
>BTW, I think you have been somehow combining identification and
authentication and making up a new word. :-)
>
>>
>>> D.  In looking at security it is important to look beyond how something is
>>> supposed to operate when it is working properly and consider how it can be
>>> attacked and defeated.  Then we need to block the ability of a malicious
>>> intruder to exploit the potential vulnerabilities we have identified.
>>
>>Right.
>>
>>> E.  If it is feasible to use the operating system or database security for
>>> protecting the appserver, we should do so.  For example, we should study
>>> carefully to see if there is a way to do all login, authentication, and
>>> password storage in the operating system and avoid doing it in the
>>> appserver.  If it turns out we need to do some of these things in the
>>> appserver, we should do them using flat files, which are much more easily
>>> protected using the operating system, rather than using the database,
which
>>> is less easy to protect.
>>
>>agree. MHO is that we should use PAM.
>>
>>> F.  On the points in your item 5, the same considerations apply as in E
>>> above.  There may well be some access controls that can only be handled
>>> within appserver.  If these arise, we should recognize ourselves and make
>>> it clear to our users that these functions are insecure against a
>>> sophisticated attacker.
>>
>>The points in my item 5 can't be handeled by the operating system. We
>>can't protect user data using the operating system if the user data is
>>stored in a database. At least, I wouldn't know how.
>
>I have always (I think) said we should look first to the operating system,
then to the database, then to the internal functionality of GNUe itself.
>
>We need to be careful to give users the flexibility to use the operating
system or the database if they can do the job.  I once had a discussion
regarding the old GEAS design that left me with the impression that GEAS
took away that kind of flexibility, i.e., you had to use the security
provided by GEAS because you couldn't trace any data from the user client
side to the database side.  I hope appserver will provide better flexibility.
>
>
>Stan Klein
>
>