RE: Where are all of the /400's going.

Joe,

But what if, for whatever reason, you cannot sacrifice unattended access to
secure data...?!?

I'm NOT arguing in favor of hardcoded user IDs and passwords.  I've changed
my mind on that issue...  But I'm not sure I want to sacrifice unattended
access to secure data...  Unattended access to secure data seem to fit the
needs of some (many?) companies.


As more and more folks get involved with B2B, I see an increasing need for
this type of solution...  Just don't know the technology, maself...  But
requiring human intervention is not only prohibitively expensive, it appears
(at least to me and Rob) to INCREASE your security risks, in some respects.
Hard for me to tell if that risk is more or less than hardcoding passwords,
but that is a moot issue, IMHO...


jt

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Joe Pluta
| Sent: Sunday, December 16, 2001 1:58 PM
| To: midrange-l@midrange.com
| Subject: RE: Where are all of the /400's going.
|
|
| > From: Evan Harris
| >
| > Fair enough Joe, but initially you argued that it shouldn't be
| done from a
| > security/data separation point of view (which I believe is a flawed
| > argument) then you made it an economic argument, which has a great deal
| > more validity, even though it is not a "technical argument" and somewhat
| > dependent on how you see things.
|
| Actually, my initial argument was against anonymous FTP (or FTP with
| hardcoded user ID and password, which is the same thing from a
| security risk
| standpoint) to an inadequately secured AS/400.  I suggested that a more
| secure environment might be (emphasis on might) to offload
| unsecured data to
| a secondary server.  I then pointed out some of the other
| possible benefits:
| lowered load on the host, lowered total cost of ownership for the static
| data, reduced dependency on host availability.  The security argument, as
| you rightly point out, is relative based on the current security setup of
| your AS/400.  A well secured AS/400, with a firewall, a NAT'd non-routable
| address, object security and exit point security should theoretically be
| able to hold its own on the Internet, and is at the same time
| LESS likely to
| succumb to script kiddie hack attacks.  My concern is that the vast, vast
| majority of AS/400's are not secured to that level.  Even if they were, if
| somebody convinces management that hardcoding a user profile and password
| for FTP is a good idea because it makes life simpler for the programmer,
| then suddenly your entire security is breached.  By moving unsecured data
| off of the AS/400, it gives the security-phobic less chance to compromise
| your mission critical data.
|
| But that's going to depend on your corporate organization.  If
| the owner of
| the AS/400 is a real nitpicker when it comes to AS/400 security,
| you've got
| a fighting chance in a real world network.  On the other hand, if security
| is handled or even influenced by someone who thinks it's okay to have user
| IDs and passwords stored in data files or programs, then I submit
| that your
| network is somewhat less than secure, and your mission critical system
| should not even have TCP/IP access.
|
| And there is, as always, a wide gamut of possibilities in between.  Always
| the individual circumstances should outweigh any "expert opinion".  Even
| mine <grin>.
|
| Joe Pluta
| www.plutabrothers.com
|
| _______________________________________________
| This is the Midrange Systems Technical Discussion (MIDRANGE-L)
| mailing list
| To post a message email: MIDRANGE-L@midrange.com
| To subscribe, unsubscribe, or change list options,
| visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
| or email: MIDRANGE-L-request@midrange.com
| Before posting, please take a moment to review the archives
| at http://archive.midrange.com/midrange-l.
|