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

> From: John Earl
>
> I think it would be beneficial to the list to reflect on what you
> _really_ just said.

Or at least your perception of it.

> You said (and I'm paraphrasing heavily here), "Rather than
> properly securing your OS/400 applications, you're better off
> pulling data off of the /400 and dropping it on a Linux or
> Windows machine that you don't have to bother securing."

I said nothing of the sort.  If you read the thread, I carefully separated
data into two categories: secured and unsecured.  This is a real and vital
differentiation.  Secure data should be on a secure server, and for me,
that's OS/400.  Unsecured data, on the other hand, is more problematic.  It
depends on the currency requirement in relation to secure data - that is,
how closely does the unsecured data have to reflect secured data.  Static
web pages by definition have no such requirement, while account status in an
online trading system requires pretty much direct access to secured data.
The less current the data needs to be, the better the argument for
offloading it for two reasons: security and system load.

The latter is pretty straightforward.  Unless you have lots of extra
processing power, there's really no reason to serve static web pages from
your mission critical machine.  As the currency requirements rise, this
argument becomes less valid in an inversely proportional relationship; if
you're constantly having to make requests to your mission critical server in
order to serve your web pages, you might as well run your web application on
that machine.

The former depends on your security philosophy.  Policies range from
complete external access to the primary AS/400 to allowing no TCP/IP access
to the box whatsoever.  Each has its place, and which one is best for you
depends on your industry, your resources and your architectural leanings.
The only one that does not make sense is the concept of allowing anonymous
access to a machine that hasn't been properly secured.


> I may be missing the real point here, but
> it seems to me that a solution such as this adds complexity,
> maintenance, cost, and when Security is involved, vulnerability.

I think you are (missing the point).  Data duplication may add complexity,
and perhaps some maintenance, and even some overhead, but properly done it
will never compromise security.  It will in fact always enhance security by
providing in effect another firewall.


> Some of the wisest words that I ever heard on this list were Evan
> Harris' response to the question "Should I put my production /400
> on the internet?"  Evan's answer was "If you don't, it won't be
> your production system much longer".  The reality of the
> situation is that if we (collectively as a community of AS/400
> aficionados) don't get security figured out on this machine to
> the point where we are comfortable putting it directly on the
> internet, the OS/400 is doomed to a dwindling legacy of green
> screen apps that may get maintained, but won't be enhanced.

I disagree with this statement.  In fact, my position is diametrically
opposed to it.  The long term solution for any distributed environment that
allows more or less free access to anonymous users is to provide security
zones, much like any decent operating system provides.  Mission critical
data should reside on a machine that is only accessed through encapsulated
server requests from trusted sources.  A middle tier should provide
connectivity to the Internet.  Even that layer should be defended against
unlimited access - this is in fact the concept behind a demilitarized zone.
One firewall allows in selected requests from outside (untrusted) entities,
into a machine that then translates those into trusted requests sent through
a second firewall to the mission critical server.  The overhead is minimal,
especially with an architecture such as servlets and JavaServer Pages.  The
web application server can reside on one box and make requests to another
machine that actually holds the data.  In what I consider one of the most
robust and secure configurations, one AS/400 running Websphere communicates
via APPC over SNA to a backend AS/400 (with no external TCP/IP access) that
actually hosts the database and the associated server applications.
Powerful, fast, and eminently secure.  Very few hackers even know what SNA
is, much less how to hack it.


> (That's not to say that the lack of properly secured applications
> is the only thing holding the OS/400 architecture back - just
> that it is now a big part of, and will in the future grow to be
> an even bigger part of, why the machine get's replaced by Windows
> and **IX solutions.)

Pshaw.  AS/400's get replaced because we as a community haven't gotten off
our collective butts and designed a simple application architecture that
takes advantage of the AS/400's strengths as a server platform.  You'd think
the imminent demise of the 5250 would cause some action, but instead all it
causes is grumbling.  In fact, the general tone of most discussions I've
seen lately center not on "how can I do this", but on "how can IBM do this
for me".  What a load of rubbish.  At age 40, I may be a cranky,
cantankerous old goat, but when I started in this industry, when we had a
problem, we actually (HORRORS!) wrote code to solve it.  If we didn't like
the comms routines that were available, we actually programmed the
communications chips ourselves in order to get distributed applications to
work.  I don't have a lot of patience for someone who complains about how
hard things are if they've never programmed an 8259 PIC chip in order to get
a Bisync communications line running correctly.  Today, if there's not an
API for it, then it's considered too difficult - too complex, too much
maintenance, too costly.

There has to be a radical shift in the application development paradigm, and
it will take (HORRORS!) programming.  Your primary business application
server has no business doing user interface, except possibly for dumb
terminals on shop floors.  For pretty graphical UIs, let the end user eat
those cycles, be it in their browser, their wireless device, or their
thick-client workstation.  Let me devote my server cycles to database
transactions (at which point maybe even those SQL requests might have some
throughput <grin>).  To do that, I need a simple, flexible, robust
machine-to-machine communications methodology (and ODBC is not the answer).


> Please don't take this note personally Joe, because your
> suggestion represents a very prevalent current train of thought.

Again, I don't think you completely understand my viewpoint.  I in no way
advocate moving mission critical data to anything other than OS/400.  I only
wanted to suggest that an alternative to unsecured access to your mission
critical machine is to separate unsecured data out and onto another box.
This is not necessary, by any means, but I prefer shutting down the FTP
server on my primary machine as opposed to programming exit point handlers.
To me, that's unnecessary programming.  Heck, on my system I have a firewall
that blocks port 21, and an internal non-addressable network, and I STILL
only start the FTP server on my AS/400 when I need it.  And I shut it down
immediately after use - I even have my own three-letter command, EFS, that
shuts down FTP, because it's so important to me that I do it.


> And while the first part of this post (and many of your previous
> posts) demonstrate that you are someone who has taken the time to
> understand /400 Security, I would hazard that the vast majority
> of our colleagues have not.  And as you already know, it's just
> not that hard (Hey, even I could figure it out so what does that
> say?).

And that, my friend, is why I bother posting at all.  I think that with a
little bit of education, our community will embrace the proper security
techniques, whichever ones they may be that make sense for their particular
organization.  If someone wants to open their machine up to the world,
that's their own choice, but I want it to be an informed choice, not one
made because they think there is no other solution.  Anonymous FTP,
unrestricted RUNRMTCMD, ODBC access to unsecured data, these are all things
that, in my opinion, need to be held up to the scrutiny of objective opinion
and shown to be what they are: shortcuts that undermine security in order to
simply avoid a little short term work.  All because there's not a API for
it, and you might have to write a little code to implement it.


> My bottom line is that security is important (else I wouldn't be
> in this business, no?) - it may not be easy, or convenient, or
> cheap, but if it's data, and it's on your /400, it's worth
> securing.

I'm with you here.  I hope I've clarified my position.  Secure data should
reside on the AS/400, and should be secured (if that's not too redundant).
The only decision is the manner in which you choose to implement access to
unsecured data: will it be on your secure machine, but with all the proper
safeguards in place, or will it be on another machine, refreshed as needed
from the secure data store.  The answer to that question will depend, but if
you've followed these posts, you should at least be able to make an informed
decision.

I hope <smile>.

Joe Pluta
www.plutabrothers.com