× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



First, do they have access to the system somehow?  Is the system exposed
to the internet or can they get on your LAN via another system (VPN or
other gateway)?  If they don't have access, your cause for concern is
reduced, but not eliminated.  Others could use their IDs internally, for
example.

Second, why are the profiles still enabled?  If they have to exist for
some reason, well, that should be mitigated so the profiles can be
deleted.  But even if they must exist while you determine if their
removal will impact the system, they can very likely remain *DISABLED
without impacting functionality.  

Third, you need to identify what exposures you offer: 5250, FTP,
ODBC/Client Access, web/cgi, etc.  For each of these, different methods
are available for locking them down.  Some may require 3rd party apps or
exit point programs to properly secure.

Fourth, I would recommend running this every week or so: PRTUSRPRF
TYPE(*ALL) SELECT(*SPCAUT) It will generate a splf listing the profiles,
their status, and their special authorities.  It also lists the last
time the profile was used.  I'd recommend disabling any non-IBM profile
that hasn't been used in 2 months and deleting any that hasn't been used
in 6 months.  For IBM profiles, I'd recommend changing the default
passwords, at least for the big guns like QSECOFR, QPGMR, & QSYSOPR.
Also run ANZDFTPWD periodically (I do it weekly).

Fifth, get the "Tips and Tools for Securing your ASeServer/400iSeriesi5"
book from the InfoCenter.

Sixth, your developers should not have IDs on your production system
(unless they also use the system as a user and are command-line
restricted & have no special authorities).  Many auditors will hit you
with a red flag for such a thing.  If you don't have a second test
system for them, consider configuring an LPAR.

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787  F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: Mike Berman [mailto:mikeba777@xxxxxxxxx] 
Sent: Thursday, November 11, 2004 8:03 AM
To: Midrange Systems Technical Discussion
Subject: Security concerns


How realistic is this scenario? We have had many programmers and
consultants come and go. They all know our IP address of our production
Iseries. What is to stop someone from using a profile that was in use in
the past and was never deleted? For example, I just found such a profile
of a programmer who left here 5 years ago, still enabled. If someone
harbored a grudge, what is to stop them from FTP's into our system and
deleting files? Or even to just shut down all the subsystems ? is there
a way to disable what one can do in an FTP session?

Thanks,



This email is for the use of the intended recipient(s) only.  If you have 
received this email in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this email without the author's prior permission.  
We have taken precautions to minimize the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any attachment 
to this message.  We cannot accept liability for any loss or damage caused by 
software viruses.  The information contained in this communication may be 
confidential and may be subject to the attorney-client privilege. If you are 
the intended recipient and you do not wish to receive similar electronic 
messages from us in future then please respond to the sender to this effect.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.