Sep 3 2009 3:36AM GMT
Posted by: Steve Pitcher
AS/400,
qsecofr,
authority,
iseries
Well, 99% of the time they don’t. They probably don’t need any special authorities either. Here are a few examples of vendors trying to break the rules.
XYZ Software
I’m working with a new application vendor (we’ll call them XYZ Software) and they need access to our system to do some custom programming and software configuration.
Here’s what they asked for right off the bat:
1. Telnet port opened up on our firewall in order to access our iSeries
2. A new user profile with QSECOFR authority.
Well, the 1st request wasn’t going to happen…period. We use other methods to allow external parties secure access to our network.
The 2nd request I would allow only if the vendor could supply detailed reasons why they would need such excessive authority. As well, this profile would most certainly be audited. Not surprisingly, what they need to do (restoring objects to the XYZ software libraries and compiling programs) doesn’t require QSECOFR authority at all. Actually, it’s not even close. In reality the XYZ profile would just need proper access to the XYZ library in order for them to compile programs and restore objects to that library.
Vendors attempt to gain much more authority than they need in order to minimize your IT staff getting in their way in the future. They don’t want the hassle of asking for authority to a command or a library so they go for broke and tell you they “need” QSECOFR authority.
ABC ERP Software
Another vendor I’ve dealt with, I’ll call them ABC ERP Software, really gets away with murder in terms of going against industry security standards. I’m sure I could make a fortune going to their customer sites and plugging the security holes, but that’s another story.
ABC Software, sadly, was given a profile called ABC which was a copy of the QSECOFR profile. Let’s say it was somewhat “needed” at the time as they were given the entire task of setting up a new iSeries server, restoring licensed programs, installing ptf’s, etc., so we let it fly. Once we got the new ERP up and running I wanted to scale that profile back to a less dangerous set of authorities.
This vendor had a fit. I was told by their Senior iSeries guru in a very curt email that if I changed anything about the profile then the ERP system would fall apart at the seams. I called his bluff and asked how and why each special authority was needed. He then displayed either true ignorance towards system security or a barrage of BS that would silence most iSeries techs afraid stand up to the scary senior analyst.
I was told the ABC profile needed *SERVICE and *JOBCTL special authorities to run a STRDBG command. Untrue! To debug a program, you only need *change authority to the object. If you don’t have *change, you need *use on the object AND *service special authority.
Also, they wanted *SERVICE so that they could access the System Service Tools. No thank you.
I was also told that they have to have *SPLCTL as they “need” to view all user’s spooled files. Again with the “need.” Sure buddy. On our payroll server. Right.
In the end I successfully debunked the necessity of 5 of the 8 special authorities ABC company wanted, including *ALLOBJ.
A few months later this “guru” stated that any user that wanted to use Fax/400 needed to have *SPLCTL. Also, I remember him stating that all users should have their MAXSTG set to *NOMAX to compensate for the lack up garbage collection in their ERP. You see, they have a GUI spooled file viewer that creates temporary PDF files in QDLS…but these files would stay there forever. Unbelievable.
Always question anyone who doesn’t have a vested interest in your company. You hold the responsibility for the security of your system, not them.
0 Comments
RSS Feed
Email a friend
