(fwd) Re: Security framework issues

[Stanley A. Klein]

This is one of 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


>Subject: Re: Security framework issues
>From: Reinhard Mueller <address@hidden>
>To: "Stanley A. Klein" <address@hidden>
>X-Mailer: Ximian Evolution 1.0.5 
>Date: 22 Nov 2002 15:26:40 +0100

>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 :-)
>
>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".
>
>> 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.
>
>> 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.
>
>Thanks,
>Reinhard
>
>-- 
>Reinhard Mueller
>GNU Enterprise project
>http://www.gnue.org
>
>
>