Re: RE: Prevent User Profile from using public authority -- SECURITY400

In my opinion, exit point products, while providing a very large amount of
value add, are NOT a replacement for an exclusionary access control model.

An exclusionary model defaults PUBLIC authority to *EXCLUDE -- i.e. access
is excluded to PUBLIC by default unless and until explicitly configured
otherwise. PUBLIC authority of *USE or greater is still appropriate for
some data in this model, but it is not assumed to be the desired access.

An open access control model assumes everyone should be allowed *READ or
higher access to everything unless explicitly configured otherwise.
Because of the heritage of i5OS many, if not most, customers have an open
access control model.

iSeries systems run in an entirely different environment today than when
the System/38 and the follow-on AS400 systems were introduced.  Many
customers that started out with the System/38 successfully achieved their
security requirements using an open access control model.  Many did not
change their access control policies while they were running entirely
different workloads, on systems that had changed significantly, and were
being used in network environments entirely different than the one in which
the original access control model was put in place.

An overview of the rationale behind my opinion is:
   iSeries is a multi-user, multi-application system.  It is too difficult
   to assume that exit points protect your data when there are numerous
   interfaces both network and green-screen that are typically used by the
   same people to access your system.  For example, does an ODBC exit point
   protect you from someone using green screen commmands to display the
   contents of a database?  If you use the exit point to prevent ODBC
   access, but the data is PUBLIC *CHANGE, and a user gets to a command
   line (either on the green screen or through a client/server application
   that doesn't prevent it), does the exit point protect the data? In my
   opinion, No.  The exit point program really protects the usage of the
   interface. It doesn't protect the data because the data doesn't have to
   be accessed through a particular interface.
   In today's networked environment, there are too many "standardized"
   interfaces designed on and for other systems that assume data accessed
   through those interfaces is protected by the native access control
   mechanism.  It is further assumed that access control has been
   configured for the data by the administrator.  Changing the behavior of
   these standard interfaces will often cause the implementation to no
   longer be standard.
   There is no guarrantee that new interfaces will have associated exit
   points.
   Exit point vendors (with valid reasons) tend to be at least one release
   behind the most recent OS release.  If a new OS release does contain a
   new interface with an associated exit point, it is likely that none of
   the vendors will have a program for that exit point for a relatively
   long time.

My assertion that exit point solutions are not sufficient to achieve the
highest levels of security, is no way a statement related to the value they
can provide.

For those of you with an open access control model -- only data that has
been explicitly denied access to is protected -- exit point solutions can
buy you heck of a lot more security than you have today.  While you're
putting an exclusionary model in place, the exit point solutions allow you
to gain a higher level of protection than you have if you do nothing at all
while planning and implementing an exclusionary model.

Exit point solutions have value beyond this also as they provide ways of
limiting access to specific interfaces based on criteria not considered by
the OS (time of day, for just one example).  These functions can be
invaluable to many organizations and add to their level security beyond
that provided by an exclusionary access control model. Exit point solutions
could also be helpful in making it easier and cheaper to move to an
exclusionary access control model.  Most already have "learning modes"
which tell you which users use which interfaces.   I would love to see an
exit point vendor use these learning modes to provide solutions that use
this type of information to help automate parts of the process of moving to
an exclusionary model.

Is changing to an exclusionary access control model from an open access
model complicated? Absolutely.  Does using an exit point product in the
absence of an exclusionary model provide value? Absolutely,  Will an exit
point solution without an exclusionary access control model be able to
provide the same level of security to an organization as an exclusionary
model plus the exit point solution?  In my opinion. the answer is no.

> Charles,
>
> Rather than risk hosing something else on your box by trying to create a
> "replacement *PUBLIC profile" or even just trying to hit every object on
> your box, it seems to me it would be a lot easier to use an exit program
for
> the ODBC/JDBC remote transactions.
>
> There are several exit program security products out there, but only one
> that I know of can afford 'pinpoint' accuracy with regard to controlling
> access via the exit point without having to modify any existing OS/400
> object authorities or user profile groupings.