Q
Problem solve Get help with specific problems with your technologies, process and projects.

Security implemented via default settings

One Search400.com member writes, "I'm looking at security implemented via default settings." Do you see a risk of having any of the above commands not set to *EXCLUDE (e.g., *USE)?" Security expert Carol Woodbury says it depends. Click over and see why.

I'm looking at security implemented via default settings. I took the approach to review 25 sensitive commands

1. ADDAUTLE -- Add Authorization List Entry
2. CHGAUTLE -- Change Authorization List Entry
3. CHGDTA -- Change Database File (using DFU)
4. CHGNETA -- Change Network Attributes
5. CHGOBJOWN -- Change Object Ownership
6. CHGSYSVAL -- Change System Value
7. CHGUSRPRF -- Change User Profile
8. CRTAUTHLR -- Create Authority Holder
9. CRTAUTL -- Create Authorization List
10. CRTUSRPRF -- Create User Profile
11. DLTAUTHLR -- Delete Authority Holder
12. DLTAUTL -- Delete Authorization List
13. DLTUSRPRF -- Delete User Profile
14. EDTAUTL -- Edit Authorization List
15. EDTOBJAUT -- Edit Object Authority
16. GRTOBJAUT -- Grant Object Authority
17. GRTUSRAUT -- Grant User Authority
18. PWRDWNSYS -- Power Down System
19. SBMRMTCMD -- Submit Remote Command
20. STRDFU -- Start DFU
21. STRPDM -- Start PDM
22. STRREXPRC -- Start REXX Procedure
23. STRSEU -- Start Source Entry Utility
24. STRSST -- Start System Service Tools
25. UPDDTA -- Update Data (using DFU)

I then reviewed whether or not the command was set to *EXCLUDE.

Do you see a risk of having any of the above commands not set to *EXCLUDE (e.g., *USE)?

This is really one of those "it depends" questions. Attempting to secure your system by securing certain commands -- especially commands like the ones you've listed here is a bit like attempting to secure your system using exit points. There are many ways around either method.

Prudent use of object level security and controlling who is given special authorities is a much more robust way to secure your system rather than using either exit points or securing commands. For example, if you control the users who have special authorities such as *SECADM to just the users that need to create or manage user profiles, there's really no need to secure the command, CRTUSRPRF, because this command requires *SECADM special authority to run.

The STRSST command requires *SERVICE special authority so again, if you control who has *SERVICE to just the users that have a business justification to have it, then you shouldn't have to secure the command. Likewise, if you have used object level security, you shouldn't have to secure the EDTOBJAUT command because, unless the user somehow has *OBJMGT to an object, they can't edit the authority of the object.

Now if your system is wide open from an authority point of view and most users have more special authorities than is appropriate, then maybe, as a stop-gap measure, it would be appropriate to secure the commands. But, in general, I would put my efforts into securing the objects appropriately and making sure special authorities are only given to the appropriate users rather than trying to make sure all the commands you've listed are secured.

However, this method is very error prone -- you have to make sure to secure all instances of the commands and make sure you review all new commands added each release. Securing the objects and limiting special authorities is much more robust approach.

Dig Deeper on iSeries security planning

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchDataCenter

Close