Used IBM Servers | New Power9 Systems | QRadar SIEM Security

IBM i Encryption Data Protection

• Users with *ALLOBJ authority or which can adopt this All Object authority through an OS400 group profile or supplemental group can access any sensitive data on the IBM i.
• Users with *USE authority can download sensitive data to their workstation
• Users with Limited Capability can run CL commands
• Applications that use adopted authority or perform a profile swap typically use *SECOFR authority

A more efficient and effective way to secure personal data for data protection compliance requirements would be to implement IBM i DB2 encryption. In addition, companies may choose to anonymize, mask or scramble personal data as a compensating control for specific use cases. Encryption does not negate the need to implement security access controls, it only safeguards the data from unauthorized access. Companies must still control how their users use the data. If an employee has authorization to read data in plain text view, access controls must also be in place to prevent the employee from downloading or running a report over the data, where the personal data would then exist without any auditing or controls in place.

Implementing IBM i encryption really only involves three primary steps: Defining User Access Permissions, Creating Encryption Keys and Executing Encryption Policies. Where to begin? Identify all the locations where sensitive and private date is stored on the system. At most companies, it has been a wild west atmosphere for far too long. If your company has not already done so, this would be a good time to educate employees on the proper procedures for handling data. In fact, educating and reminding employees about the dos and don’ts should be an ongoing process.

QRadar IBM i Offense

Configuring the IBM i to forward security and system event logs to QRadar SIEM can be done a few different ways, but in order to do it correctly; in LEEF format, in real-time, with GID and enriched event log information, you need an IBM i event log forwarding tool designed for the QRadar SIEM. There are IBM i security event log forwarding tools that can be used for QRadar that will send event logs in real-time and in CEF SYSLOG format, and even a couple that support LEEF, but only one includes QRadar QID for mapping, log enrichment and is on DSM support list. These features are important for QRadar's automatic log source discovery, parsing IBM i event logs properly for offenses, alerts and reports, and so that SOC operators can make sense of the logs. Similarly, all the IBM z Mainframe event log sources also require a forwarding tool that is able to format all the unique event log types and designed specifically for IBM QRadar.

The IBM i has many different event log sources, of which most SYSLOG and SIEM forwarding tools can only format and send System Audit (QAUDJRN) and Message Queues like QHST. However, most companies will also need to forward other event log types for compliance and audit requirements, like sensitive database access logs for File Integrity Monitoring (FIM), Network, SQL Statements, Open Source protocols, Privileged Access Management (PAM) events, Port usage, and Commands issued from a workstation. Other logs sources that companies also sometimes forward are web application logs, third party application and performance data, but these log sources are not typically required.

IBM i Privileged Access Management (PAM) solutions have various levels of flexibility for implementation and integration with existing applications and ticketing systems that need to be considered before purchasing. Assessing your IBM i Security requirements for implementation will be key to ensuring the IBM i PAM solution you choose meets your all your use cases, as well as environmental and compliance requirements.

First note, Privileged Access Management (PAM) terminology used by most technology sectors and compliance regulations refer to processes more commonly known on the IBM i (iSeries AS400) platform as Profile Swapping and Adopted Authority procedures. Terminology aside, the goal of PAM is to limit the number of powerful profiles (user IDs with excessive special authorities, powerful user classes and users with no or partial capability limits) on the IBM i to a bare minimum, and only temporarily grant elevated authorities (privileges) to user profiles with a specific need (use case) to complete a task or provide access to sensitive data which is outside their normal duties in a controlled, permissions based manner. Other companies start using PAM simply because they want to stop wasting time giving out passwords for powerful profiles on a regular basis. There are a number of ways to grant privileged access authority for IBM i users which are much more granular than Open platforms, and each PAM solution has different capabilities that will determine the success of your implementation.

In general, all IBM i PAM solutions should be able to control which menus and commands users can access, as well as which actions they can take for specific objects or files. When a user is performing a profile swap or adopted authority, an extensive audit trail should be captured in the system journal, as well as possibly screen captures in some instances. Ideally, Privileged Access Management functions should be automated, seamlessly integrate with both internal and external applications, and without disrupting to existing processes.

Database clustering involves database replication to achieve high availability (mirroring, redundancy and disaster recovery), workload balancing for performance or scaling (queries, reporting, business intelligence, analytics and data warehousing), maintenance (upgrades, migration, testing and development), database consolidation and other objectives for data access, efficiency and better decision making. It is use database clustering and replication services where the source and target databases are at different version levels and even different types of databases all together, such as PostgreSQl to Oracle replication, or DB2 to SQL. Database clustering can be implemented for a mix of on premise, virtual and cloud environments, using any of the following replication scenarios for various objectives:

• from one database source to one target database (one way)
• from one database source to multiple target databases (distributed)
• from multiple database sources to one target database (consolidated)
• from one database source to one or more target database cascaded to one or more targets again (cascaded)
• one or more database sources to one or more target database (bi-directional)
• one source database to two different databases or even a hybrid combination of any of these scenarios (hybrid)

Most database clustering solutions cannot meet complex business requirements when disparate platforms are a part of the equation or if complicated and long distance replication scenarios exist. Businesses with unique or complicated plans for database clustering should check out the advanced Database Replication software for clustering, with built-in conflict resolution and collision monitoring. It allows companies to replicate in real-time and transform data to and from the following databases: Microsoft SQL Server, Microsoft Azure SQL, IBM DB2, Oracle, Oracle RAC, MySQL, PostgreSQL, Teradata, IBM Informix and Sybase, of which the source and targets can be different combinations. Removing these technical barriers is key to real-time data sharing, which do not require abandoning existing investments and spending a lot of time and money on integration.

Database migration and conversion projects can be a time consuming and costly endeavor without the right software, and converting large complex production databases with real-time replication and transformation requirements significantly compound the risks. Using a database migration and conversion tool to map fields of disparate databases correctly and keeping them in sync is key to a successful and non-disruptive conversion. Critical business applications utilizing the database to be converted will add risk to the migration process. Traditional database migration and database converter processes usually take hours or days for large databases, costing businesses unnecessary downtime. Some companies have wasted millions of dollars in failed database migration and conversion projects using internally developed tools or having to rely on multiple database converter tools to get databases in sync, tested and matching accurately.

No Time for Downtime
Not an uncommon database requirement. Accuracy is the number one goal of any successful database conversion, but minimal or no downtime for production databases is a close second. By using the right database migration software, both requirements can be accomplished very easily. Using real-time replication will keep the target database in sync, which will make testing easier, improve efficiency, and ensure no downtime incurs of critical production applications. Companies wanting to make adjustments and enhancements to the new database. Using a database conversion and transformation tool that can perform this process on the fly, and keep the data in sync using database replication would be ideal for testing applications on new database.

Implementing IBM i Multi Factor Authentication (MFA) and Password Self-Service (PSS) as an integrated solution allows companies to enjoy the cost savings of automation, while enhancing IBM i security and addressing compliance requirements at the same time. On the surface, IBM i MFA, Password Self-Service and 2FA software solutions already have a lot in common. If you are thinking of implementing IBM i MFA, 2FA or Password Self Service, you may want to consider implementing them together to gain both the cost savings and security benefits.

Caution
When buying any IBM i MFA Multi-Factor Authentication, 2FA Two-Factor Authentication or PSS Password Self-Service software solution, it is important to note, most compliance regulations require a single step authentication process to be used, as multi step authentication have been proven to be insecure. IBM i MFA, 2FA and PSS solutions will either use authentication factors or need answers to security questions, which will then use either a single or in multiple step process. In a multi-step authentication process, users will complete a validation process successfully, and then be presented with a new screen for the next authentication factor or question. This security flaw allows a hacker to confirm a user’s security screening information. Single-step authentication performs the entire validation process from one screen, which prevents the hacker from confirming which one failed.

IBM i Multi-Factor Authentication (MFA) is a critical cybersecurity defense required by PCI, FFIEC and 23 NYCRR 500 in Section 500.12b, stating any company providing financial services within the state of New York must implement MFA to protect system data and applications for all users that have external network access, or use an approved access control equivalent. IBM i Multi Factor Authentication prices are very affordable, simple to implement and provide the quickest means to protect against the cybersecurity threats 23 NYCRR 500 was drafted to address. There are companies claiming the price of MFA solutions are too expensive or too complicated to implement. These companies are likely the same companies that score security defenses as their number one priority each year, yet have made minimal effort to circumvent the simplest security vulnerabilities that only require effort.

Why does 23 NYCRR 500 require Multi-Factor Authentication? The majority of all security breaches are the result of poor user authentication practices, phishing scams and related credential thefts, so the state of New York made Multi-Factor Authentication a commonsense cybersecurity defense requirement. Although the IBM i has traditionally not been as susceptible to most cybersecurity threats like other platforms, with the adoption of SSO, EIM and other cross-platform integration efforts, implementing MFA will only enhance the platform’s security posture. Unlike PCI, the 23 NYCRR 500 requirements affects companies of every size equally. In addition to implementing IBM i Multi-Factor Authentication, the OS400 has many other security and access controls that can be enforced to tighten security. Simply strengthening system value password policies for example, can significantly affect chances of a security breach.

IBM i SFTP FTPS Secure FTP

SFTP Secure File Transfer Protocol
Secure File Transfer Protocol, also called SFTP, Secure Shell FTP and SSH FTP, is a Linux and UNIX data transfer tool that is supported on the IBM i platform, provides entire session encryption to and from any platform, and allows use of server-side public key authentication certificates and client-side authorization certificates. SFTP is ideal for automating file transfers and commonly used by MFT Managed File Transfer solutions. The IBM i SFTP and FTPS MFT software is the only product that fully supports password-based SFTP in batch mode and is the only software that fully implements this authentication security measure on the IBM i according to the standard. Multiple firewall configurations commonly cause problems for FTPS sessions, which is why SFTP is often chosen. SFTP utilizes a single connection for authentication, sending commands, transferring files, and any other processes involved.

FTPS File Transfer Protocol
The FTPS protocol utilizes old school FTP and adds a TLS or SSL encryption layer to verify a secure connection. FTPS was initially created for systems to communicate and run commands securely, not to transfer files. When implementing FTPS on IBM i, consider using a MFT solution that supports Clear Channel Command CCC for intelligent firewall negotiation and proxy server (port management) support. You will also want to be able to audit FTPS access to make sure that the sessions authenticate properly and comply with regulations. Using FTPS explicit mode (also known as FTPES), the FTPS client may choose to use an encryption method for communication. The FTPS server will determine if it will grant the unsecure client access or refuse the connection. FTPS implicit mode does not allow negotiation, meaning the FTPS server will refuse an unsecure connection and usually uses port 990.

Iseries File Integrity Monitoring

File integrity monitoring FIM for IBM i requires monitoring the system security audit journal and DB2 database journals to detect unauthorized changes to files and their contents. FIM projects are usually due to compliance regulations such as PCI, 23 NYCRR 500 and like regulatory requirements, which will significantly reduce the file integrity monitoring scope to specific database files and object changes in QAUDJRN. In addition to implementing file integrity monitoring, you will need to ensure user authorities and access control policies are correctly defined and monitored for changes going forward. On an iSeries, many of these settings can be defined from the system or using iSeries Navigator, although it makes sense to also use IBM i security exit programs for access control policies.

Monitoring iSeries database field level changes will likely be the primary focus of the FIM compliance objective, which requires the DB2 files to have journaling enabled to audit the file activities, such as open, read, update, add, delete and close operations. As a result, any changes made to or within the database file will be recorded, including user who made the change, when the change occurred, type of change, program name used to make the change, job information and like details of the event. As a result, these audit entries are automatically put in an associated audit journal which can be queried, reports can be run against and alerts can be triggered by an IDS. Depending on the compliance or audit requirement, it is likely the FIM event logs must be forwarded to a SIEM security tool like QRadar or a SYSLOG Server tool like Splunk which are used to centralize event logs for security monitoring.

Implementing iSeries Profile Swapping and Adopted Authority policies is a great idea for reducing the number of powerful profiles on the IBM i, especially if most users only need elevated authority for specific tasks or occasional access to sensitive data. On the IBM i (iSeries AS400), the Profile Swapping, Adopted Authority and Elevated Authority procedures are more commonly referred to by compliance regulations and other platforms as Privileged Access Management (PAM) proceedures. However these processes ultimately have the same objective, limiting the number of user profiles on the iSeries that possess unnecessary special authorities (or having a powerful user classes or have no or partial limited capability), and then use policies to grant the required elevated authorities for a specific task or need to access sensitive data that is outside the user’s normal role. Elevated authorities can be granted by several different means on the iSeries, and PAM solutions greatly differ in their flexibility, how they can be implemented and integrated into applications, change management systems and ticketing systems.

When looking at solutions and specifications for Profile Swap, Adopted Authority and PAM requirements, consider your iSeries environment and all external systems and processes you will need to play a role in the end solution. Some likely features needed for a successful PAM implementation may include: