Tweet
Hello to all, I have the following problem : I was hired by a client to check the AS/400's status(I am an AS/400-consultant myself) and I have now arrived at the security of the system. unfortunately people have been building and building and building applications for years without taking any notice of security(#$&*@). What I am facing now is a machine with about 74 *Secofr-profiles, groupprofiles with *secofr-class(all of them by the way), in effect ; it's an incredible mess ! My beautiful task is to set these things straight. As this is a productionsystem I do not want any interruption of daily activities. Now the first thing to do would be to remove as much of the authorization as possible. For this I need to analyze the groupprofiles, their members, the objects they need to have access to(analyze the jobdescriptions), look for adopted authority, etceteta. I have not found a manual, redbook, whitepaper with a checklist of any kind and that is what I need. It might be something like : 1. Check the objects owned by the user and move them to the groupprofile. 2. Analyze the used jobdescriptions, maybe even reduce the their number. 3. Analyze the authorization required at the moment to access the necessary objects so this authorization can be granted to the groupprofiles 4. Remove the remaining authorization 5. Etcetera. Does anybody know of a checklist like this, maybe you even have one yourself ? Any help will be appreciated mucho, Rob.
-
-
Cleaning up the house...
Maybe if you approach it as though you are going to set up security from scratch, you can determine what authorization is needed. The Basic Security manual - SC41-5301-00 talks about setting up security. You sound like your on the right track anyway. Just make sure that you keep good records of everything you do. After the successful completion of this project, Can you then provide us with your checklist? Good Luck -
Cleaning up the house...
I'll keep notes, no problem.. As for the manual, after working with the S/38 and the AS/400 for sooooo many years I have ofcourse read it lots of times but I don't think it can help me here. I cannot start from scratch because of things like Jobschedule-entries. Say an entry was submitted by a user with *SECOFR-authorization and is supposed to run under this profile(it happens, honest I've seen it !) or even another one with *SECOFR. If I alter the authorization of said user he or she may work fine interactively but the batch will fail at night because the batchjob belongs to a completely different applicationgroup(would you believe it?). It's just that sort of thing that I'm looking for. Nobody here knows what they've done in the last 8 years so half of them denies the problem exists and the other half cheerfully says : Happy hunting Rob... right...great....thank you.... For me this has more to do with my professional pride : I want to solve this without the users ever detecting it....As I have just solved a complete systemcrash without the SAVSYS-tapes already(when they where getting desperate..) I am gaining some reputation here as 'Mr. Fixit' and I want to keep it that way as long as possible ;-) Thanks for your response and feel free to make suggestions anytime, the list will be more complete that way. Rob.Comment
-
Cleaning up the house...
Rob, This is by no means an answer, but it may be an approach to consider. Try boiling down the current security to its most common denominator. From the sound of things it seems that the answer to any security problem has been to make them SECOFR. Once you can find the common denominator, consolidate the group profiles and have all of the users based on the group profiles. Make sure that the group profile owns all objects and that the user profiles are all set for OWNER(*GRPPRF). Once you have everyone accessed to everything on one common profile, you can then begin to break the security down into its appropriate groups. I did this to go from level 20 to level 30 and it worked fairly well. You may be a little ambitious trying to completely insulate the users, there seems to always be a gotcha. HTH John PComment
-
Cleaning up the house...
Possibly you could try to seperate the online users from the Jobscheduler entries. Leave the JSE's with *secofr and get the users straightened out, changing the JSE's where necessary because you are changing the user. The users have *secofr is probably your biggest security problem. I hope they don't expect you to have this worked out by Friday.Comment
-
Cleaning up the house...
Hah, they don't even understand the importance of the current situation here(well except for a few people) so as far as most people here are concerned I don't have to finish this at all...... As you both state it's the *SECOFR-class that messed things up. The first thing I will have to do is make an analysis up the application-sets and set up a scheme to separate the libraries. Then I will set the groupprofile-authorization straight(leaving the *secofr-bit). Then I can start to test one application after another by changing the groupprofile to something a little less omnipotent than *SECOFR and see what happens. If things go wrong, programs start to fail, etcetera I can change the groupprofile back to the original god-like status and correct the failure. Any comments anyone ? Thanks for the response so far, Rob.Comment
-
Cleaning up the house...
Rob, Now that I'm thinking about it, the *SECOFR authority probably won't be a problem. That controls things like user profiles, passwords, system values, etc. I would be more concerned about the profiles that have *ALLOBJ. That is what will really wack your applications. John PComment
-
Cleaning up the house...
John, You're confusing the special authority *SECADM with the user class *SECOFR. *SECOFR gives a user ALL special authorities like *SECADM, *ALLOJB, etc just like the profile QSECOFR has. And besides, if you have *SECADM authority, you can set the user class too! Chris This thread topic reminds me of a Talking Heads song!Comment
-
Cleaning up the house...
I recently completed a security project, the problems were different although the steps taken should be the same. 1) Analyze the existing scheme to work out how things are running, if the users have *ALLOBJ, it's not difficult!!! 2) Design the proposed scheme. 3) Plan a migration strategy. Issues / Comments How many applications are on the machine? Do users have more than one profile?, one for each application? How will you set library authority? Group profiles?, beware of users (or their group) OWNING the production objects. Users having *USE authority to production data opens ODBC and FTP issues. How will new user profiles be created?, using documentation or programatically.., ensure they are always created consistantly. Transfering data to and from the AS/400 will have issues when you lock down the applications. Change management, if objects have a specific authority structure, how will it be preserved during object updates. Removal of *SPLCTL, users can't start printers anymore. Adopted authority, (this is how we solved alot of the problems) has risks associated with it's use. Trigger programs do not adopt authority from the program stack, need to be run as USER(*OWNER). Sorry for the brain dump....... Paul.Comment
-
Cleaning up the house...
You're right, the TalkingHeads bit was intentional...glad to see someone notices...:-) Rob.Comment
-
Cleaning up the house...
Keep those braindumps comin'...! I will publish the final plan here when I've finished it... Thanks 4 the input, Rob.Comment
-
Cleaning up the house...
All such messes just reflect the absolute uniqueness of the human brain. Each such mess is going to have its own weirdly wonderful, screwball attributes and I would not imagine it to be a easy task to analyze these things and look for their common attributes... but if you find such, PUULEEEEZE post it here.Comment
-
Cleaning up the house...
Hey Rob, I'm curious as to how you are going to pull off this feat. Will you set up an enviroment with adopted authority where everyone can still run everything and slowly tighten security through the program objects? That's probably what I would do since it also addresses other loopholes such as ODBC, FTP, etc. without requiring lots of registered exit programs on each new release of OS/400. I could type up some ideas along this line if you want. Of course, I'm not an expert on OS/400 security and as I type this I'm reminded of an old saying: the ignorant always speak first! Let me know. ChrisComment
-
Cleaning up the house...
I think the problem is that although it only takes one or two system-engineers a day or so to totally wreck the security of the AS/400, it takes specialists an incredible amount of time to repair the damage. Mostly because mentioned system-engineers do not document their changes(in this case ofcourse, I don't wish to generalize). In this case the previous engineers kept writing useful utilities wich were abandoned when they were between 50 and 80 % finished. Perhaps MidrangeComputing publishes too many good ideas ??? :-) I will post the results when the operation is complete(and no sooner, I don't like giving incorrect information ;-)). It is one hell of a job as you are all aware but what can ya say ? "It's a dirty job but somebody's got to do it..." Rob.Comment
-
Cleaning up the house...
Any updates on this subject? I need to do the same here. Thanks.Comment
Comment