RE: Where are all of the /400's going. Was: QUSER on ODBC requests -- MIDRANGE-L

> From: John Earl
>
> While I agree on the task of separating data into "secured and
> unsecured", I disagree that this distance requires the physical
> space afforded by two different hardware platforms.  If you've
> got the robust security features of OS/400 available to you, you
> can separate the data on the same box.  For you Separation seems
> to be at the hardware level, I maintain that library level would
> be adequate.  But I suspect you and I will have to agree to
> disagree on this point.

No, John, no disagreement.  I think the problem here is that you have the
idea that I am promoting a specific solution.  Nothing could be further from
the truth.  As I've said in other posts, a properly secured (firewall,
internal non-routable addresses, object security, exit points) OS/400
platform can hold its own just fine, although I've also stated that a
majority of OS/400 implementations are not properly secured.

My primary argument is against user IDs and passwords being publicly
available, and nobody has come up with a business case where I couldn't do
the same thing without requiring the security breach of giving out an AS/400
password.

>> Static web pages by definition have no such requirement,
>
> I think that this paragraph's reference to system load can be a
> convincing argument for offloading static web pages to a less
> expensive (to purchase) platform.  However, the argument that
> "static" information has no need for security just doesn't make
> sense.  There is lot's of static information that is well
> deserving of the best protection money can buy. My Social
> Security number, the Coca Cola formula, Sate Farm's actuarial
> algorithms, etc. etc.  Just because data does not normally change
> doen't mean it should be left unsecured.

We've got some terminology issues here.  "Static" as applied to HTML does
not mean "unchanging".  "Static", in the very specific context of web
applications, means data stored directly in HTML, and not read from a
database.  Because of that, there are no AS/400 security issues for static
data, and that's all I really meant.  There may be web security issues, but
that's not the focus of the discussion, and I'd rather not dilute the thread
to start talking about website security.  Let me make my position very
clear:

1. Data offloading is one possible solution to access to unsecured data
2. Offloading has other benefits, such as decreased system load and TCO
3. All secured data should be on the AS/400
4. AS/400 user IDs and passwords should not be stored anywhere off the
AS/400

I don't know of anybody who stores secure information such as their social
security number in a static web page.  If they were showing a SS# over a web
page, it would almost certainly be delivered dynamically from a database.
That's not to say it couldn't happen, however.  If someone did have social
security numbers hardcoded into a web page, that would be a good example of
secure static data.  But at that point, we're veering off into the land of
website security, not AS/400 security.