Why limit CLI access on AS/400?

45 pts.
Tags:
AS/400
AS/400 - CL Command
AS/400 security
A little background... I am new to the compliance and auditing field and recently introduced to the AS/400 system and I am constantly seeing in best practice environments that the CLI be restricted from most users and or at least limited capabilities set to *YES. To the point... The system administrator for the AS400 is adamant that the current menu structure security method is sufficient without restricting the CLI or changing the setting limited capabilities to *YES. My question, is there a way to prove or disprove the menu control is sufficient to secure the system? Additionally, I have reservations that the sole administrator has all special authorities, is that unjustified or what is the recommended special authorities for the system administrator?

Software/Hardware used:
AS400, Infinium, Agilysys

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 6  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    The major (and often sole) reason for CLI restriction is that "menu security" is generally valid when the AS/400 is accessed through direct-attach terminals, and CLI restriction fills related areas that may be unintentionally exposed via menu options. As soon as Ethernet (or token-ring, etc.,) network access becomes available, "menu security" is practically worthless. There are numerous ways to prove it, but it would be difficult to provide specifics without knowing the system content. -- Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    For "Special Authorities", there should be a couple general profiles that have them though the distribution of those across the few profiles is up to the needs of the system. In general, there is no need for any non-administrator or non-supervisor profile to have any of the 'special authorities'. If a general user demonstrates a need for one of those assigned to their profile, it's almost certain to indicate flaws in the security scheme that has been set by system administrators or application developers. These flaws might arise from applications that are many years old that have never been modernized. You might consider a tool such as PowerTech's Compliance Assessment for a review. Other tools from other vendors are available, but I'm not familiar with them. -- Tom
    125,585 pointsBadges:
    report
  • Avelino
    The clients access the AS400 through a Windows domain. What I'm mainly having an issue with is proving that there is indeed segregation of duties between the associates or that the current setup is inadequate. 
    45 pointsBadges:
    report
  • TomLiotta
    Can you define "the associates"? That's the first use in this thread. Proving inadequacy only takes locating a single unprotected critical system resource through any non-menu interface. The locating should be demonstrated using a general user profile. But saying how to do it requires showing how to determine which resources are important on your system and then teaching the generally available non-menu access methods. That becomes a system analysis task first and a general course in networking second. Neither is trivial. If the teaching doesn't happen, then there's no way to support any evidence with authoritative documentation. By running a dedicated tool from a respected vendor, you at least have evidence that says whether or not actual analysis is needed. It's very hard to take the next steps otherwise. -- Tom
    125,585 pointsBadges:
    report
  • Avelino
    Associates in this instance is i.e. Buyers, Accountants, Accounts payables and controllers. I am trying verify that the Buyers are not able to do the functions of the Accounts payables personnel. Infinium is running on the AS400 to manage the finances and Agilysis's MMS is used for requisitions. I definitely need to see where or if any user profile that does not have menu access to the GL or SubL can access these sensitive files.
    45 pointsBadges:
    report
  • TomLiotta
    Without tools and without system experience, it can be tricky no matter what platform you're looking at. For future reference, AS/400 is the original name of the platform. A number of years ago, new hardware and OS upgrades brought "iSeries" as the platform name. The name indicated the convergence of hardware with other IBM series. Then a new generation became System i, and latest is a name, Power Systems, applied essentially to all IBM platforms where the differentiator is only the OS that is installed. For the latest in the AS/400 line, the OS is "IBM i". So, if you see names change, those all essentially refer to the same platform. The "AS/400" name has stayed in mind for much of the market, but I'll mostly refer to 'iSeries' here.   Your first tool set should probably be as much of the IBM iSeries Access (or "System i Access" or even the very old "Client Access"; the name you'll see depends on the age) product as you are allowed to install on your PC. The first tool from that you should become familiar with is iSeries Navigator, or "iNav".   iNav is a graphical PC view of the system. The elements that you can see on the iSeries will be affected by the authorities that your profile has on the system. By logging in with different profiles, you should see different libraries (schemas) and different lists of files for example. Actions performed against objects on the system should succeed or fail based on authority.   (This assumes your system uses standard authentication, i.e., user and password. If it uses Kerberos, single-signon, it will be different; but it's not common yet.)   When you start iNav the first time, you'll need to define a connection to the system. You'll want to set it for "Use default user ID, prompt as needed" or "Prompt every time". That will make it easier to investigate effects from using different profiles.   You'll also want to create test profiles on the server. Create one that generally matches how each type of Associate is set up. You can then use iNav to connect as each user type to see what features and options are allowed.   You might start iNav and connect as user BUYER. Then drill down into Databases and Schemas. A default set of schemas (libraries) should appear. If you expand a schema, you can select to show the list of tables (files) that BUYER is authorized to access in that schema. And when the list shows, you can right-click a table to View the records in it. Or instead of View, you might select Edit to see if a change will be allowed against a row in the table. ( A change won't be effected until after you type a value and move out of the cell. It'll either work or show a window saying 'not authorized'. Obviously, that's not something you'll want to test immediately.)   If you right-click the 'Schemas' node in the left-hand panel, you can select the 'Select Schemas to Display' option. That allows you to add schemas other than a default set.   A secondary "tool" will be the CWBLOGON command. This allows you to set or remove a cached user and password for iSeries Access. When you logon through iNav, iSeries Access can remember your credentials. If you want to switch from BUYER to CONTROLLER, you can close iNav, and run CWBLOGON from a Windows command line. One CWBLOGON parameter will clear the cache for a server so that you can choose CONTROLLER when you start iNav the second time.   At this point, you have a basic tool to see what is accessible through network interfaces to users of different stuff on the system. You can find out which users can pull what data off the system to their PCs and what objects can (potentially) be modified outside of normal non-network means. I can't tell you what should be allowed, of course.   It's likely that simple investigation of the iNav tool will take time. Once somewhat familiar with it, you'll take more time with all of the possible objects you might access and operations that can be performed. You'll probably want a library of your own with a couple files in it. You can use those for practice, to see what happens when you use 'Edit' or 'Delete' instead of 'View'. You can set authorities on your own objects to see what happens with different ones when BUYER, for example, tries to do things.   Once you feel comfortable with simple things, you might post back here and perhaps we can check some really dangerous things. Post back also if you run into obstacles. An initial problem might simply be that no administrator can help you install iSeries Access.   Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following