A Short History of IBM i Security

Transcription

1 WHITE PAPER Four Powerful Ways to Use Exit Points for Securing IBM i Access A Short History of IBM i Security In the early years of the AS/400, there was little if any communication to/from the system, so implementing security was relatively simple. The approach was primarily managing user authorities, securing user access through menus and applications, and perhaps implementing rudimentary object-level security - and in many cases, this was sufficient. In the 1990s, with the advent of the Internet and the growing need to provide communication between systems and business partners, IBM opened the system to TCP/IP. Over time, the different ways the system could be accessed grew, and the job of securing the system became increasingly more complex. With systems becoming more open came an increase in breaches, and with high-profile breaches came a host of compliance regulations that further expanded the ways - and thus the complexities - in which organizations needed to secure their systems and protect sensitive data. Today, the job of managing security on IBM i can be complicated, requiring dynamic technologies and processes that can respond quickly to ever-evolving threats and new regulations. There are many different approaches and technologies you can use to keep your IBM i secure. In this whitepaper, we ll discuss how numerous exit points provided by the IBM i OS can be utilized as a powerful means to monitor and secure four important levels of access within the IBM i: Networks Communication Ports Databases Commands 1 Four Powerful Ways to Use Exit Points for Securing IBM i Access

2 Exit Points and Exit Programs Powerful Tools for Access Control IBM introduced exit points to the AS/400 in 1994 with V3R1 of the operating system, which provided administrators and developers with hooks that could be used to invoke one or more user-written programs called exit programs during a wide variety of OS-related operations. For instance, most types of network communications have their own exit point. Therefore, an exit program can be created and registered to the exit point for a particular network-access protocol. For example, an exit point program could be written that not only monitors and keeps logs of all FTP activity, but also allows or denies specific users the ability to transfer a file based on many parameters, such as user profile settings, IP addresses, object permissions, time/date windows, etc. Because a wide variety of information can be passed to the exit program and the exit program can often be designed with a very granular, rules-based logic, it is possible to allow or disallow a specific type of activity under very specific circumstances. This kind of control provides the ability to implement a nuanced, contextual approach to securing access, which has numerous benefits. In addition, it s important to keep in mind that exit programs are always invoked by the OS prior to the consideration of object-level security. This means that when exit programs are properly created, they can control the conditions of access for even powerful users. If you re not utilizing exit points and exit programs, you cannot achieve comprehensive IBM i access control. The challenge of exit programs is that they can be laborious to create and difficult to manage, which is why third-party solutions exist and can significantly streamline the process. More about this later in the e-book. With this introduction to exit points and exit programs, let s look at the four levels of access that exit programs help to secure. 2 Four Powerful Ways to Use Exit Points for Securing IBM i Access

3 1 - Secure Network Access Security challenge Network protocols such as FTP, ODBC, JDBC, DDM, DRDA, NetServer, and others make it possible for users to connect directly to backend databases on the IBM i. This provides great convenience for users who want to use data in spreadsheets, business intelligence applications, and development environments. The problem, however, is these protocols, if not properly controlled, open the systems to potential hackers or, more commonly, to internal users who may intentionally or unintentionally create problems. For instance, a user may normally be provided *USE or *CHANGE authority for a sensitive file through the normal course of using a business application to do one s job. The function of the application might be designed to narrowly control what the user can see or do with that sensitive information within the application. However, when the same user accesses the application database through FTP, a copy of that sensitive file could be downloaded. If the database is accessed by ODBC, the user could change or delete any kind of data in the file. In addition, if network access isn t controlled, it is possible to remotely execute commands. For instance, without additional protections in place, commands could be executed via FTP, ODBC, and RMTCMD through functions such as RCMD, REXEC, and RMTCMD, respectively. In addition, SQL statements could be executed remotely via ODBC, JDBC, and DRDA if access isn t properly locked down. How exit programs help remediate the threat IBM provides dozens of exit points that cover most network access protocols, which means that exit programs can be created and assigned to these exit points, not only to monitor and log activity but, most importantly, to control access by a variety of criteria. When access is controlled through network exit programs, only the specific operations defined by the exit program can occur. 3 Four Powerful Ways to Use Exit Points for Securing IBM i Access

4 It should be mentioned that the IBM i OS provides another way to protect some aspects of network access outside of exit points. Application Administration, part of Operations Navigator (or its green-screen version called Work with Function Usage), provides a partial solution that is able to control which users can access particular network functions; however, this option doesn t provide any logging, nor does it provide the ability to define granular rules in the same way as exit programs. 2 - Secure Communication Port Access Security challenge There are a handful of network protocols that don t have their own exit points and thus can t be protected in the same way as protocols that have specific exit points. These network protocols include SSH, SFTP, SMTP, and others. In addition, organizations may need to control communication access in a way network or other types of exit points cannot because it is not possible to specify a port number in these other types of exit points. For example, it may be important for a specific type of network connection to be able to use only one or more secured ports. How exit programs help remediate the threat IBM provides socket exit points that make it possible to develop exit programs for securing connections to your IBM i by specific ports and/or IP addresses. This covers part of the gap caused by the lack of protocol-specific exit points for SSH, SFTP, SMTP, and others, but it is important to keep in mind there are some limitations in terms of how socket exit programs can function. For instance, the socket exit program that controls inbound communications is limited in that it can only be defined to allow or disallow communication on specific ports and/or IP addresses, while providing some other parameters such as day and time. By contrast, the socket exit program that controls outbound communication can be defined with rules that cover various user parameters in addition to ports and IP addresses. All of this aside, socket exit points can provide a necessary level of protection, especially when paired with the other types of exit point access-control methods that are described in this e-book. 4 Four Powerful Ways to Use Exit Points for Securing IBM i Access

5 3 - Secure Database Access Security challenge Standard object-level security only goes so far in controlling access to sensitive data. There can be many different situations in which you need a more fine-grained approach to whether access to data is allowed or denied. One area of particular vulnerability is the increasing use of opensource protocols that access data, such as JSON, Node. js, Python, Ruby and many other open-source protocols. Certainly, these provide innovative ways to integrate the IBM i to other IT processes and are being used with increasing frequency; however, these protocols don t have their own exit points and therefore can t be protected in the same way as network protocols. Without properly securing database access, problems could easily occur, whether it s a user who accidently corrupts data or worse, an internal or external actor who commits fraud or steals sensitive data. How exit programs help remediate the threat One particularly powerful exit point is called Open Database File, and it allows development of exit programs that protect sensitive data from any kind of access. The added layer of security this exit point provides is significant because of its ability to invoke an exit program whenever a specified file on the system is opened, whether it s a physical file, logical file, SQL table, or SQL view. As with other exit points, your exit program can be defined to audit all activity, such as the user, the method of access, the date/time, and the operation (read, update, add, or delete). Plus, the exit program can contain a granular set of rules that control under what conditions the file can be accessed and by whom. 5 Four Powerful Ways to Use Exit Points for Securing IBM i Access

6 4 - Secure Command Access Security challenge No matter if accidental or deliberate, the incorrect use of commands by users can cause considerable damage, whether it s deleting files, restoring libraries, ending processes, or worse. Certainly, access to commands can be controlled to some extent through user profiles and object-level security, but organizations often need a more refined approach to allowing or disallowing commands, particularly for users with powerful profiles. How exit programs help remediate the threat IBM provides exit points that cover the use of commands, thus making it possible to develop exit programs that allow or disallow access to any command within very specific circumstances, regardless of whether the access attempt comes from a user performing a command-line function directly within the IBM i, through network access, or otherwise. Because command exit programs supersede normal object-level security, they add an additional, very useful layer of security that can control the use of commands even for users with powerful authorities such as *ALLOBJ or *SECADM. As with other types of exit points, command exit programs can be defined in such a way that each command can have its own specific rules of usage, while providing logging of any activity. 6 Four Powerful Ways to Use Exit Points for Securing IBM i Access

7 Exit Programs Do It Yourself vs. Third-Party Solutions Now that you know how exit points and exit programs can control access in many powerful ways, the next step is to start creating your own exit programs. However, as mentioned at the beginning of this ebook, it can be challenging for many IBM i shops to develop and manage their own exit programs. There are several reasons for this: It is a time-consuming, complex, and error-prone process to create, properly test, and maintain exit programs, Whenever there are new PTFs or updates to the OS, exit programs often need to be updated accordingly, System performance can suffer if exit programs aren t designed correctly - this is particularly the case with high-volume ODBC/JDBC applications Fortunately, third-party solutions exist and therefore make it easy for you to create, deploy, and manage exit programs even if you don t have any knowledge of programming. Well designed solutions bestow multiple advantages such as: Providing an easy-to-use interface for defining access rules as well as logging and alerting functions of the exit programs Reducing the chance for the introduction of errors into exit programs Ensurng optimal performance of exit programs Guaranteeing that exit programs stay current to the latest threats and OS capabilities Offering a critical separation of duties that many auditors require when it comes to the development of software that controls and manages security functions 7 Four Powerful Ways to Use Exit Points for Securing IBM i Access

8 Let Syncsort Help Security on the IBM i shouldn t be treated as a static process given the ever-evolving nature of threats, the new and changing compliance regulations, and the increasing ways the platform needs to connect to internal and external systems. This is why, wherever possible, IBM i access control should take a granular, dynamic, contextual, data-centric approach. Syncsort Assure products for IBM i provide market-leading business continuity and data protection for IBM i servers - spanning high availability, disaster recovery, migration, data replication and security. In a world that accesses data in 24x7 timeframes, Syncsort Assure products have been designed to make your data available whenever and wherever you need it, backed by powerful audit and security capabilities. Learn more at: 8 Four Powerful Ways to Use Exit Points for Securing IBM i Access

9 About Syncsort Syncsort is the global leader in Big Iron to Big Data software. We organize data everywhere to keep the world working the same data that powers machine learning, AI and predictive analytics. We use our decades of experience so that more than 7,000 customers, including 84 of the Fortune 100, can quickly extract value from their critical data anytime, anywhere. Our products provide a simple way to optimize, assure, integrate and advance data, helping to solve for the present and prepare for the future. Learn more at syncsort.com Syncsort Incorporated. All rights reserved. All other company and product names used herein may be the trademarks of their respective companies.