I am always amazed at how easy it is to establish a Telnet connection with another system. Just open a command box on your PC and enter the TELNET command along with the IP address of the system you want to connect to. On most IBM i boxes, you'll get the familiar signon screen and as long as you have a legitimate user profile and password, you're in business.
An audacious burglary got me to thinking about security on the IBM i and how a similar situation might easily exist at many shops where doors are left open for no good reason.
A security policy is a set of statements that describes how you view information security for your installation. In each application area, the policy should describe how information created and stored in the application is going to be treated from a security perspective.
The IBM i OS has supported object signing ever since release V5R1 became available. Object signing, simply stated, works by having each object on your system signed by the originator that guarantees that the object is what it claims to be and that it has not been altered.
You would probably never think of leaving the front door of the building open all night with the lights on. By that same measure, you should not leave your system exposed to intentional or even accidental abuse when you have it within your grasp to correct the situation and you have all the tools to do so at your disposal.
The IBM i OS includes a command that lets you keep track of the trigger programs that are installed on your system. The command lets you run a master list of all trigger programs and then, periodically, just list the trigger programs that are new or have changed.
IBM continues to proudly tout the IBM i as a highly secure environment and one that has been very resistant to virus and tampering. So, it was with some surprise when I found the CHKOBJITG (Check Object Integrity) command on my system. If the IBM i OS is so secure, what's the deal with this command?
An Authorization List is a special system-level object that resides in the QSYS library with object type *AUTL. Your system can contain multiple Authorization Lists and it is recommended that they be created along application boundaries. So, one list could be used for Payroll while another list can be used for Inventory, and so on.
Often, in our zeal to keep things safe, we make it hard for everyone else to just do their job. If that's happening in your shop, I'd take a second look at what you're doing. Security should be done in such a way that legitimate users (your customers) should be able to do their job without having to jump through any hoops, not even little ones.
A backup plan generally has two objectives. First, to be able to recover the entire machine in the event of a catastrophic loss of your processor. This recovery can be either on your own machine, following repair, or at an off-site location. The second objective is to be able to recover an individual object in the event of accidental or purposeful object loss.
Security incident response consists of several steps and processes that you should document for your organization. There are all sorts of event types that you may be faced with and each one can have a number of responses or actions that you will need to consider.
There are two commands in the IBM i operating system that you can use to create database lists of objects for this audit check. The Display Authorization List Obj (DSPAUTLOBJ) command can be used to create a database list of all objects secured by your Authorization List. The list will include all objects currently on your system, regardless of library used, that are secured by the list.
For those of us who grew up with it since the early AS/400 days, security requirements for the "native" library file system are pretty easy to understand and administer. When it comes to the Integrated File System (IFS), however, things can work differently. This tip will explore some of the differences and how best to try and deal with them.
There are lots of aspects of a security audit, but one control all auditors seem to have in common is seeing proof that your IBM i program base is not tampered with. This tip will give you a simple method for providing this proof, plus it gives you a good opportunity to quickly review all changes to program objects by just scanning a few simple reports.
What is unique to each application, however, is the object level security setup that protects your basic data and programming elements. This is what I want to explore here by reviewing a few key practices that, over time, will simplify your security administration task.
A security policy created and implemented without end user participation is destined to always be a problem. If your end users, however, are asked to participate and buy into the policy, then the results will be a much smoother implementation.
Computer Security, as a specialty, is still fairly new. Chances are, you did not get into this field by taking it as a major in college or going to a technical school and specializing in the field.
The classic definition of a consultant is "someone who borrows your watch to tell you what time it is", and to a certain degree, this is true. But a good consultant will explain to you every aspect of your situation.
I have been asked several times recently "How did you learn so much about security on the IBM i?". In this tip, I will try to let you know how I got to this point and, perhaps, it will help you on your journey as well.
What most organizations need is a Security Evangelist. Someone who knows what the problem is and really believes in the message.
As an IBM i security officer, you've spent a lot of time doing two main tasks. First, establishing a security policy, and second, setting your system up to enforce that policy. Once you have these two tasks done, then you can sit back and relax ... right?
RECENT POSTS
CATEGORIES
© 2021 KISCO SYSTEMS LLC
54 Danbury Rd. | Suite 439 | Ridgefield, CT 06877
