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. --
This mailing list archive is Copyright 1997-2013 by MIDRANGE dot 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 here. If you have questions about this, please contact