IBM i 25: Object Orientation
Today’s IBMi25 chapter is Object Orientation. You can find it on our Facebook page: bit.ly/IBMi25. Today’s guest blogger is Terry Ford (firstname.lastname@example.org), who works in IBM’s Lab Services organization with a specialty in security.
As an “old-timer, ” my career started out as a System/3 programmer at a local government shop in Illinois. When I was introduced to the AS/400, the notion of object orientation was foreign and unsettling. I thought, “Am I going to need to relearn everything?” Needless to say, those concerns quickly disappeared once I learned the basics of object orientation and the benefits it provides.
The AS/400 architecture, which carries forward to IBM i today, offers a distinct advantage over other platforms in the marketplace. With its object orientation, the operating system works through a comprehensive set of interfaces to define the operations that are allowed for a particular type of object. Each of these operations includes security as a base component that enforces a very stringent set of rules based on the object types on the system. For example, you can call a program but you can’t call a file. You can run a command but you can’t run a data-area object. Calling a program requires one set of authorities, while running a command requires a different set. On other systems that don’t have an object orientation, however, everything is a file. Rules can’t easily be implemented on these systems that could prevent someone from running malicious scripts stored in a document or file. Generally, opening a file on these systems requires the same level of authority, regardless of the file type, and thus it’s much more difficult to control access.
Recently, while performing a security assessment on a customer’s system, IBM i object orientation proved very helpful. A commonly used exploit on file-based systems is to place a Trojan Horse in the system path. Trojan Horses could be anything - not necessarily a file with an .exe or .bat extension. On IBM i, if the exploit is to be present, it must be an object that can be called through OS-approved interfaces. Through security assessment software developed by Lab Services, we were able to identify for the customer some programs that had been placed in the operating system library and had the potential for subverting defined security controls. This was easily detectable because of the object orientation of IBM i, which allowed us to quickly mitigate the threats on the customer’s system.
In the past year, we have improved our security assessment tool to isolate threats more quickly and present them in a dashboard. From a central location, a customer can look across his enterprise and see how well its security policy is being administered. This dashboard is a synthesis of more than 1,000 pieces of statistical and static information that define security for a system and includes analysis of users, work management, networking, applications, system configuration and more. User defined options allow a customer to enhance the reporting and grading of results. All of this was possible because of the object orientation of the IBM i operating system. Object orientation does not prevent someone from trying to create malicious software, but it does make some kinds of attacks impossible, and makes identifying the rest much easier.