Manage Learn to apply best practices and optimize your operations.

Granting QSECOFR access

We use a packaged tool to lock down our TCP/IP application access (FTP, ODBC, RMTCMD, etc.). I am the administrator of this access. I have always gone with the idea that our most vulnerable profile (QSECOFR) should not be granted this remote access. But more and more, software installation routines are requiring this ability and some of them require the specific profile QSECOFR. Typically, I would grant access on a case by case basis, but this has become a bit of an administrative overhead. Plus, it leaves the system vulnerable for a period anyway.

What is your take on granting QSECOFR access to the TCP/IP services (eliminating the administration)?
I'm with you. QSECOFR is definitely one of the most vulnerable profiles (along with profiles that own well-known applications and have default passwords.) QSECOFR is always the one that will be tried first by the hackers since it is well-publicized. In my opinion, the protection is worth the hassle and administrative overhead, but that's a call you will have to make for your particular situation.

P.S. I understand the need to install a product with a powerful profile, but there is absolutely no excuse for a vendor to require you to sign on as "QSECOFR." It's irresponsible for vendors that require you to do that!


The Best Web Links: tips, tutorials and more.

Search400's targeted search engine: Get relevant information on security.

Ask your systems management questions--or help out your peers by answering them--in our live discussion forums.

Check out this Search400.com Featured Topic: Top ten security tips

Dig Deeper on iSeries system and application security

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.