While many industries, including financial services, healthcare, e-commerce, manufacturing, and transportation, utilize the IBM i, the perceived high level of inherent security it offers no longer reflects reality.
By Joydip Kanjilal
Although many organizations worldwide continue to rely on IBM i as their primary computing platform, securing your IBM i environment is an imperative. The core elements of IBM i security thrive on the object-level security model and authority structure (PUBLIC, adopted authority, etc.), where every resource is considered as an object with explicit permissions granted to it.
In this article, we'll examine how you can harden the security of IBM i environments to combat cyber threats.
IBM i Security Challenges: Misconfiguration and Integration Risks
As businesses connect their on-premises IBM i to other public clouds and to other organizations, new security vulnerabilities may arise, particularly due to poor security configurations, exposure of the integrated file system (IFS) to ransomware via shared Windows drives, and increased insider threat activity.
The Integrated File System (IFS) works similar to a typical Network File System (NFS) when accessed through NetServer (SMB Shares). Often, companies expose their NetServer but lack access controls, allowing attackers to bypass traditional user terminal controls.
Although the IBM i environment is not an insecure platform, you should know that there may be significant gaps between how its security is perceived and the actual security it provides. While the IBM i platform is still considered secure, configuration drift, integration complexity, and the expanded attack surface of hybrid deployments are key challenges you should be able to handle. It should be noted that to implement effective security on IBM i (AS/400) in hybrid environments, you should adopt a layered approach that combines IBM i's built-in security features with modern cloud-based security tools.
Traditional perimeter security is no longer adequate as we begin integrating the IBM i (AS/400) with cloud vendors, API-driven environments, and remote work. Organizations must rely on Zero Trust, End-to-End Encryption, and Automated compliance monitoring to secure their IBM i (AS/400) environments.
Understanding the Problem
Cybersecurity is a conglomeration of people, technology, systems, and processes that work together to protect against threats posed by malicious actors. With cyber security threats on the rise, organizations worldwide have been investing in strategies to combat them.
There are several types of cyber threats, including ransomware and other malicious software, phishing scams, information theft, and, most recently, threats arising from the use of AI.
Application-level Security
IBM i environments are designed to run Java and RPG applications via web and mobile devices. Securing these applications is important because there may be several security threats.
To minimize these threats, an organization will need to implement secure coding standards, use least-privilege access, disable unnecessary permissions, separate runtime users from administrators, and implement auditing logging.
Data Security in Db2 for i
DB2 for i uses a multilayered approach to ensure comprehensive security, including AES-256 data encryption for data at rest and TLS encryption for data in transit.
You should enforce SSH and FTPS/SFTP. When working with your database connections, ensure that your JDBC/ODBC drivers are configured to use TLS encryption. Additionally, you should encrypt sensitive data at the field level by implementing field-level protection using FEILDPROC exit programs.
In addition, a combination of field-level security allows authorized users partial access to sensitive data while enabling the application to function and comply with applicable PCI DSS and HIPAA standards.
Additionally, if you're using either the Db2 Service or the XMLSERVICE to expose your business logic, you should treat them as internal services secured within your network perimeter.
While you can use the IBM i Access APIs to create REST endpoints that interact with your legacy RPG programs, it is good practice to use your own API Gateway instead of exposing the IBM i Access APIs directly to your users.
Securing Hybrid Architectures
As we integrate hybrid environments in which the IBM i is part of a larger, increasingly targeted ecosystem, we need to rethink how we secure the IBM i (AS/400) application and data to meet current enterprise and industry compliance standards.
Connecting IBM i to cloud services in a hybrid architecture increases the attack surface due to misconfigured networks, exposed interfaces, and data replication. You should never connect your IBM i directly to the public internet; instead, connect using a secure API Gateway (i.e., Ocelot, YARP, Kong) in the DMZ or at the edge of the cloud.
You can leverage exit programs to validate not only user credentials but also the context. For example, you can block users from accessing the database after hours and allow ODBC access only from specific IP addresses.
You should design your authority collection strategy based on what users need access to, and provide an accurate mapping between users' requirements and the current authority collection records in your legacy system. You should also create a starting point for building your new API layer based on the principle of least privilege.
You should also take advantage of Auditing via QAUDJRN when building modern business applications. This will facilitate a single, unbroken audit trail from an HTTP Request to the underlying data change(s) occurring in the database.
Executive Perspective
Modernizing IBM i security means minimizing the impact of a security breach by adding security measures and implementing strategies to maintain the platform's overall reliability.
IBM i security should be viewed as part of an enterprise's overall cybersecurity strategy, not just a single platform-level concern. You should adopt a multi-layered defense strategy that addresses all aspects of identity, network, endpoint, and data security across the enterprise.
Modernizing IBM i involves not only shortening release cycles and adding a modern graphical user interface (GUI), but also reducing the potential blast radius of future cyber threats by implementing new security protocols, preserving the unparalleled reliability of the IBM i platform, and addressing legacy security vulnerabilities.
Practical Hardening Checklist
The following is a practical hardening checklist that captures the possible remediations you can follow:
- Following the principle of least privilege: As the name suggests, you should minimize user privileges to only allow a small number of users access to sensitive resources to protect the integrity of these resources.
- Removal of default passwords: You should run the ANZDFTMW command to determine how many profiles have default passwords (i.e., passwords are equal to the username), and remove those passwords from all profiles.
- Enforcing TLS when making remote connections via APIs: You should use transport layer security (TLS) for remote access through application programming interfaces (APIs), so there is a secure communications channel from the .NET front-end components to the legacy RPG back -end using an encrypted transport.
- Identify sensitive data fields within Db2: You should apply column-level masking and encryption to protect sensitive data residing in the Db2 tables and limit exposure to your critical data.
- Apply PTFs regularly: IBM i uses PTFs to receive security patches, bug fixes, and feature enhancements. You should schedule regular monthly time slots to download and install PTFs, with a focus on security-related PTFs.
- Implement encryption: You should implement encryption to secure critical data from unauthorized access, data breaches, and ransomware.
- Lock down the exit points: You should lock down the exit points because if you don't have an Exit Program, anyone who is aware of the credentials can download your entire database.
- Maintain proper IFS Hygiene: You should scan the Integrated File System (IFS) and revoke public access
Takeaways
To protect your IBM i environment, you must implement a proactive, multi-layered cybersecurity strategy. You should ensure strong security measures are in place to create a secure IT environment and enhance your protection against potential cyber threats.
Remember, cybercriminals continually change their tactics, so you will need to stay a step ahead of them. Your strategy should take into account the current security landscape and be adept at addressing unique challenges.
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online