RE: iSeries Security in Computerworld

Joe,

An engaging reply.  You cover a lot here, but it is early on Sunday
morning and I have limited time before the family wakes up, so I'll try
to address just your major themes:

The number of shops at 20 and below is quite small.  And
I'll bet that if
you get rid of the people in your survey running at
security level 20 (who
are nearly running without security anyway), that the
percentage of default
passwords drops as well -- I'm sure the few systems at
level 20 skew some of
your other numbers.

My theoretical answer is:  Like it or not, systems that run level 10 or
20 are still part of this community and I think they should be included
in the study.  IBM sold 225,000 S/36's, and a vast number of those
applications were brought over to OS/400, and the overwhelming number
would have been migrated to QSECUIRTY level 20.  If something bad were
to happen to their machine and the story end up on the front page of the
WSJ, you can bet that the wrap would go against System i and not S/36.

But my practical answer is that there were no Level 10 boxes included in
the study, and as you expected, only about 7 or 8 level 20 boxes (I
don't have the raw data in front of me this morning, so I am just
looking at a graph).  That's less than 5% at QSECURITY Level 20 and
below.  Given the number of S/36 environments that are still out there,
I would not consider this to skew the numbers terribly.  I'll understand
if you disagree.

We do agree on one thing: unfettered ODBC access is
anathema to security.
There are FAR more people opening up their machines via
ODBC access than
those that need to worry about weak passwords.

I agree that unfettered network access (ODBC, ftp, RMTCMD, etc.) is a
really, really big problem in this community, and the study does address
that aspect of security.  But we designed the study to take a broad look
at security and explore multiple areas.  After someone does one of these
assessments, the trick is for them to decide which area is, for them,
most critical and/or most easily corrected.  If you have a lot of users
with default passwords, that is something that is pretty easy to
correct, and you could have it completed in a day's time (more if you
are a really bureaucratic organization :) ).  One of the values of the
individual assessment is that it focuses your attention on your largest
security exposure and gives you some direction on what to do first.  For
some folks it will be regulating ODBC, for other people it will be
password strength.  You can't boil the ocean, so you have to break the
problem into manageable pieces.

A couple of miscellaneous points.  First, you can read the study for
your self - it is on our web site (www.powertech.com) , and I encourage
you to do so.  We're not saying that the OS/400 has major security
flaws, what we are saying is that most shops are not managing security
well enough to be compliant with the various regulations that are being
set for IT.

Second, you mentioned that none of you clients would show as bad as the
average, and I don't doubt that.  It is, after all an average and we
would expect some customers to come in above the line and some below the
line.  If you (or any Midrange-L member) want to actually measure your
customers against the average, send me a private note and I'll arrange
for an assessment for you.  Who knows, you could skew next year's
numbers in a more positive direction.  That's OK with me, we are not
trying to achieve a particular number, we're just reporting the numbers
we receive.

And Third, relative to the JOBD exploit at QSECURITY level 30 and 40, if
you have a JOBD with a user ID attached (Such as QGPL/QBATCH, which has
QPGMR attached), and you are at QSECURITY level 30, and the user has
*USE authority to just the JOBD, the user could submit a job as user
QPGMR.  At QSECURITY level 40 or 50 the user needs not only *USE
authority to the JOBD, but also *USE authority to the user ID QPGMR in
order to submit a job as QPGMR.  That is a pretty significant difference
between level 30 and higher.

Also at QSECURITY level 30, it is possible to do pointer manipulation
and hijack a pointer that has more authority than what you should have -
effectively giving yourself *ALLOBJ.  It used to be that you had to code
in MI to accomplish this, but now you can use C or RPG to do pointer
manipulation.  All good reasons to abandon QSECURITY level 30.

jte


--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
Celebrating our 10th Anniversary Year!
 
 
 
 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--