According to the latest Help Systems IBM i Marketplace survey (https://www.helpsystems.com/resources/guides/ibm-i-marketplace-survey-results), the number one concern of IBM i professionals is “Cybersecurity and Ransomware.” Sadly, that concern is well founded. I have heard recently from several IBM i shops that they had been victims of cyber attacks. The damage from these attacks is very real and very expensive (for more on the cost of cyber attacks, check out this IBM report: https://www.ibm.com/security/data-breach).
Too many IBM i shops believe that if they avoid exposing their IBM i directly to the internet, they are protected from hacking attacks. I’ve even had IBM i professionals tell me that they have been granted security exceptions because access to their IBM i was “internal only”. The problem with that strategy is that an increasing number of attacks are coming from inside the internal network. They come from sources like personal computers that have been compromised via a phishing attack or from someone’s personal device that has been hacked. (For more on the danger of these “insider attacks”, see this IBM report: https://www.ibm.com/security/digital-assets/services/cost-of-insider-threats/#/
Fortunately, there are some well-defined steps you can take to protect your IBM i applications and data. A great way to start is to think of security in terms of a Zero Trust framework. In a Zero Trust framework, you assume that an attack can come from anywhere outside or inside your network. In a Zero Trust framework, you no longer focus on a “network perimeter”, in which you attempt to secure the boundaries of your network and then assume everything inside is safe. Instead, you manage access requests, policy enforcement and protected resources.
For every access request, you must know
- Who is the requester
- How do I verify the requester’s identity
- To which resources is the requester authorized
- What is the minimum amount of access I need to grant for the request
- For how long is access granted before I require reauthentication
Who is the requester?
Many IBM i users rely on Basic Authentication for identifying the user who is accessing an IBM i resource. With Basic Authentication, you send a native IBM i User ID and Password with each request. Although this has served the IBM i community well for many years, in a Zero Trust environment, you should look at more modern technologies. Instead of using Basic Authentication, users are moving to encrypted web token authentication. In this technique, a user is signed on through an authentication server application. The application sends the approved user an encrypted token. From that time forward, all communication is performed using the encrypted tokens. These encrypted tokens can be set to expire in whatever time period you desire. They can be valid for a single call, for 10 minutes for an hour, a day, or forever. You can also expire a token on demand if you want to revoke a user’s authentication immediately. When the token expires, the user must reauthenticate with their ID and password. Importantly, these user IDs and passwords are NOT native IBM i credentials, so you can carefully limit what the user will have access to. Using encrypted tokens means that you are not exposing credentials to potential discovery as they are sent across the network or while they are stored on a requester’s device.
Verifying the Requester’s Identity
For an added level of safety, you can verify the requester’s identity either through a third party or via multifactor authentication (or both). Third party verification involves using a technology like OAuth 2 for signing on via a trusted outside source (eg. Google, Facebook, OKTA, etc.). You can also control access to your IBM i using Single Signon technologies like LDAP, Active Directory, Kerberos, SAML, etc.
Which Resources Should be Made available to the Requester to and What Data/Functions can they Access
In a Zero Trust environment, it is important to limit a requester’s access to only the minimum amount of data they need to fulfill their request. Unfortunately, we see many IBM i shops simply opening up ODBC/JDBC connections to their database without restrictions. Although this makes things simpler for potential requesters, it also opens up much more data to potential attacks.
For How Long Should Access be Granted?
Once you have granted access to a resource, you need to determine how long that access should remain available to the requester before they must reauthenticate. There is a tradeoff between convenience for the requester (not asking them to constantly reauthenticate) and secure access (the longer a requester has access, the more time a hacker has to compromise the connection). Once again, you should be guided by providing the minimum time necessary for the requester to perform their required function.
Setting up a Zero Trust environment may sound daunting but the task can be significantly simplified by setting up an API layer around your IBM i for all system access. The API layer makes it possible to use Open Source modules for implementing encrypted token support, OAuth and multifactor authentication. You can even have terminal emulation sessions access the IBM i via the API layer so that you can add additional layers of protection (like MFA) to your 5250 sessions. The API layer can be used to limit access to each requester based on their identity and role so you can ensure requesters are only getting the data they truly need. The API layer also gives you a central “choke point” that you can use if you need to quickly block access to your system.
For more detail about setting up a Zero Trust environment, you can download the National Institute of Standards and Technology’s guide to Zero Trust here: https://csrc.nist.gov/publications/detail/sp/800-207/final
Or, reach out to us at www.eradani.com/contact and we will set up an appoint for you to discuss secure architecture with one of our Eradani experts. We look forward to hearing from you!
