Document Management, EDI Software, MICR Check Printing, ACH Payment Solutions








About PowerTech®

PowerTech provides software that allows you to control and monitor access to all Special Authorities.  PowerTech also offers PowerTech Network Security a Network Exit Program product that effectively prevents unauthorized data access via Data Authorities.

About the Author

John Earl is Vice President and Chief Technology Officer for the PowerTech Group, a Seattle based company that focuses on building security solutions for OS/400, i5/OS, and the IBM i operating system.


Laser Checks/ePayment

EZPayManager/400

  • Secure check printing
  • Electronic payments
  • Payment notifications

View Quick Overview of Payment Solution

ACOM's Advanced Selected Access Security

ACOM’s EZPayManager/400 with Selected Access Security was named a Product of the Year in Tech Target’s Search400.com Awards Program.


Learn more about ACOM’s Selected Access Security module, a very thorough security overhaul of the entire software suite.

 Home> Articles > Securing Printed Checks on OS/400, i5/OS and i Operating System

Securing Printed Checks on OS/400, i5/OS and i Operating System

By John Earl, CTO PowerTech®

For users of automated check printing software, security is of utmost concern.  ACOM software gives you the ability to protect that important check writing capability within the confines of their application, but what about the IBM operating system?  Does it help protect your financial data as well?  Unfortunately the answer is: ‘it depends’

It depends on how good of a job you have done configuring your IBM O/S for security.  The good news is that your ACOM software runs on one of the most securable operating systems available.  But that doesn’t make it somehow magically secure forever, you must get involved.

There are two areas of security that you will want to pay attention to in order to protect your check writing capability; Special Authority and Data Authority.  OS/400 special authorities allow a user to bypass regular authority rules and take on superhuman abilities to look at and/or change data on your system. 

 

Special Authorities
The first and most powerful Special Authority is *ALLOBJ.  Users with *ALLOBJ Special Authority can read, change, and delete everything on your system.  You must have at least one of these users, but you shouldn’t have, for example, 20 (we’ve seen systems with even more!).  No matter what you do, a user with *ALLOBJ can always find a way to access every application you have on the system.  Therefore it is important to limit, and closely monitor users who have this capability.

The next most powerful Special Authority (relative to printed checks) is *SPLCTL Special Authority.  Users with *SPLCTL can read change or delete any job or printed output on your system.  *SPLCTL Special Authority is complete and total for all spooled objects (jobs and reports) and cannot be limited or controlled.  This would give a user the ability to look at payroll checks, or to print a check run more than once, among other things.  I have analyzed systems for over 15 years and have never found a reason why an end user would need to have this Special Authority in their profile.  When Users think they need this, it’s better to give them *JOBCTL Special Authority instead.

*JOBCTL Special Authority operates the same way as *SPLCTL Special Authority, but with one critical difference.  *JOBCTL users can be controlled and even denied access to certain print queues if you choose.  This allows you to give programmers and system operators (for example) access to every printer out queue on the system except PAYROLL and AP_CHECKS.  In this way you allow the IT staff to get their jobs done, without exposing critical financial data to the programming and operations staff.

There are eight types of special authority in OS/400.  FIGURE 1 shows average number of user profiles for each special authority, according to a study of over 200 companies conducted by PowerTech in 2008.[1]

Data Authorities
Data Authorities are how the operating system defines who can read, change, add and delete data for various files on your system.  These are the authorities you would see if you entered the command:

  • DSPOBJAUT OBJ(QGPL/QDDSSRC) OBJTYPE(*FILE)

 

If a user has *USE authority, they will be able to read the contents of the file.  If the user has *CHANGE authority, they can read, add, change and delete records in the file, and if the user has *ALL authority, they can do all of the above, plus delete the file.  And while many users only see the same menu every time they sign on, many users are learning that there are a number of other ways to get to DB2/400 data - tools such as ftp, or ODBC using Microsoft Excel, for example. 

Access to data through ftp and ODBC can be controlled, if you use a solid Network Exit Program product.  Exit programs can detect and prevent users who attempt to access data outside of their regular menu’s and report those security exceptions to proper authorities.

Final Thoughts
Running your business on the AS/400, System i and Power Systems using i for business is one of the more secure ways to run your business.  But security requires that you diligently pay attention to the details, and make changes and upgrades to your system as appropriate.

# # #


1. The State of System i Security 2008 (PowerTech White Paper, 2008). 

Visit the PowerTech website to download the complete study.


EZPayManager/400
Secure check printing, electronic payment, and payment notification

View Quick Overview of Payment Solution

ACOM Solutions
2455 Meadowbrook Parkway NW · Duluth, Georgia 30096
Phone: (770) 279-8955 · Fax: (770) 814-7011
©2008 ACOM Solutions, Inc. IBM Midrange, AS/400, iSeries, and OS/400 are registered trademarks of the IBM Corporation.