Highly Secure API Enablement for IBM i

August 1, 2022 Daniel Magid

The explosive growth of APIs (Application Programming Interfaces) over the past few years has dramatically transformed how business is conducted. APIs allow customers to increase revenue by leveraging new channels to reach their customers; they facilitate cost reduction by automating manual processes and raising an organization’s responsiveness. In many industries, the benefits of APIs are so compelling that it is already impossible to compete or participate in a business supply chain without supporting APIs.

However, opening up your core IBM i applications to API connections also carries risks. According to the Gartner Group, APIs are rapidly becoming the number one target for malicious attacks on a company’s IT systems. After all, APIs are a sign on your front door saying, “Welcome – check out what we have to offer!” Appropriately implementing API Security will allow you to take advantage of the power of APIs while ensuring that you are not exposing your company to unnecessary risk. In fact, since APIs can act as a gateway to all system functions, a strong API strategy can significantly enhance your overall security beyond just your APIs.

The Risk Is Real And Costly

According to the IBM 2021 Cost of Data Breach study, the average cost of a data breach is just under five million dollars. One attack can easily cost dramatically more than implementing comprehensive protective measures.

Importantly, paying attention to security is essential, even if you are not connecting your IBM i to anything outside your network. Every year, the number of attacks that originate within a company’s network increases. The IBM 2020 Cost of Insider Threats study shows more than 60 percent of companies experienced 20 or more insider attacks during the previous year. That percentage has almost certainly grown. Insider attacks can occur when a user’s PC has been compromised (e.g., via a bad email link or phishing attack). The hacker then launches an attack using that person’s trusted credentials.

According to that same study, the average cost of an internal attack using stolen credentials is $871,686. Since most companies are experiencing multiple attacks, the average annual cost is $11.45 million. In addition, the tooling we currently use has a variety of potential security vulnerabilities. (See this recent article in IT Jungle).

Fortunately, there are well-documented steps you can take to protect your systems and significantly reduce your risk. This article will cover some basics and provide links to additional resources. I’ll cover:

API security terminology
Secure authentication and encryption
Zero Trust, or using APIs as a security layer
Multifactor authentication
Managing and monitoring API connections

The great news is IBM supports the latest in security technologies required for safe API enablement.

API Security: The Basic Building Blocks

SSL, TLS, OAuth, JWTs, SAML, LDAP – sometimes it seems like security conversations devolve into a hodgepodge of cryptic acronyms. This section covers the basic building blocks of API security and will help you understand what those acronyms mean.

Here is what Secure Sockets Layer/Transport Layer Security (SSL/TLS) looks like:

Internet architecture is like our system for delivering physical products. The physical Hardware devices are like the warehouses and stores to which goods are delivered, the Internet layer is like the highway system with its roadways and exits, and the Transport layer is like the trains, trucks, and ships moving the goods. Security (TLS) is implemented at the Transport level where you send your products (functions and data).

The Internet facilitates communication between various devices over a wide range of technologies. So, the foundation of our diagram (below) is the actual hardware we are connecting and the transport mechanisms we are using for sending and receiving data. This includes our network wiring, wireless devices, VPN devices, microwave dishes, satellites, etc. Because implementing security at the hardware level would require writing specialized code for every different device, this communication is left open.

Security is implemented at the transport level – the level at which you send your data. Hence the name Transport Layer Security (TLS). At this level, your data is encrypted, and you must provide authentication as to the identity of the parties exchanging that data.

There is some confusion in the marketplace about the difference between TLS and SSL. TLS replaced SSL as the transport security layer. To be up to date, your Internet connections must support TLS 1.2 or later. TLS 1.0 and TLS 1.1 still supported SSL, so they were vulnerable to the same security issues as SSL. If you are still using SSL, TLS 1.0, or TLS 1.1 connections, your security is outdated and has known vulnerabilities. Fortunately, IBM supports the latest TLS versions on IBM i (in fact, they are required on the latest operating system versions).

Secure Authentication

As you can imagine, it is critically important to know who is accessing your API and ensure they are who they say they are. Initially, this was done using a technique called Basic Authentication, which is a method for sending user IDs and passwords from a Web browser or service caller to the target system to identify the user. The user ID and password will be sent on every call. To eliminate the need for the user to sign on every time, the user ID and password are stored in the browser or on the calling server. This creates several significant security vulnerabilities:

Every time you send a user ID and password across the internet, there is a danger they will be discovered
Basic Authentication does not require encrypting of those credentials. They can be 64-bit encoded. Anything that is 64-bit encoded can be decoded, further increasing the risk of discovery.
Credentials stored in a browser can be discovered in their storage location. Many companies are not storing these credentials in a secure vault, another serious potential security exposure.
IBM i users often send IBM i user IDs and passwords for these credentials, thereby providing native access to the IBM i to anyone who can discover them.

Because of these concerns, most API providers (Google, Microsoft, Amazon, etc.) have stopped supporting Basic Authentication. Unfortunately, many IBM i users continue using Basic Authentication and 64-bit credential encoding, which puts systems at risk.

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. They will not need any native IBM i access credentials.

To enhance your security even further, you can add third-party verification that the user is who they say they are. This is where technologies like OAuth are used. Using OAuth, you can check with a trusted third party like Google, Facebook, Microsoft, and others to verify the user’s identity.

With OAuth, the user (Requester) first signs on to a trusted third party (Google, Facebook, etc.) to get an encrypted token and access code. They then send that to the API server they are attempting to access. The API provider then sends its access code to the third party to verify it is valid. Once they have verified that the user is who they say they are, the API provider gives access to the Requester. On the right, you see a typical implementation of a UI for OAuth access. The user can either sign on directly or via the third-party verifier.

Authorization

Once you have successfully authenticated the user, you must control their access. Many companies implement “Zero Trust” policies in today’s security-conscious world. In a Zero Trust environment, users are given access limited to just what they need for the current operation they are performing (more on Zero Trust below). Since the authentication token identifies the user and the role, the API can limit the user to only those functions and data appropriate to who they are and their role.

For example, we set up an API for order inquiries that allowed users to see the details of orders and their current status. If the user was a customer, they could only see their orders. If the user was a company salesperson, they could see all the orders for all their customers. If the user was a company manager, they could see all orders for all customers. Every call went through the same API but based on the user ID and role; it granted limited access to each user. Importantly, since they were not using native IBM i credentials, they could not access any other resources beyond what the API provided. So, the potential damage could be extremely limited even if the credentials were compromised and used for an attack.

Open Source Modules

The ability to use open source modules drives huge increases in development productivity. Yet, I often hear concerns from IBM i users regarding the security of open source software. Ironically, open source modules can often be more secure than writing code yourself. The popular modules are constantly being vetted by the top security people in the world, and security vulnerabilities are being continuously patched. However, since using open source means using code written by people outside your organization, you need to pay attention to what you are using. The good news is that many tools are available to help you choose open source modules wisely.

Open source package repositories (npmjs, pypi, github, etc.) provide crucial information on the usage of each module. You should check out the popularity of the module (how many people are downloading it), activity (how often is it being updated and how recently), and outstanding issues (are there many outstanding problems). These statistics can help you decide how risky a particular module might be.
Source scanning tools can help identify potential vulnerabilities in your software and in open source modules. Tools like Appscan will tell you if you have known vulnerabilities in your code (there are many free open source tools for this as well). The good news is that thousands of organizations continuously scan the most popular open source modules.
With open source, you get the source code. You can always review the code to see what it is doing (although this could be a big job which is why people use source scanning tools).
Testing tools can help you determine how well an open source module works. The open source you are integrating with your application should be tested along with the code you are writing.
Package Managers like YUM, RPM, and NPM, which IBM provides on the IBM i, will help you keep your open source modules up to date with the latest security patches. Many of the problems with the use of open source have resulted from failures to keep them up to date.

Zero Trust

Implementing a Zero Trust policy means assuming that any user might be an attacker at any time. Some of the steps in implementing a Zero Trust policy include:

Limiting users’ access to the minimum data and capability needed to perform a specific task. You should avoid simply providing an API that exposes all the data in a table or set of tables. Try to limit the user’s access to only the data they need.
Checking user authentication and authorization before each operation.
Setting time limits on the validity of access tokens.

A well-designed API strategy can implement these kinds of functions for you. For more information on Zero Trust, check out this article from IBM.

Multifactor Authentication

Multifactor authentication means using a combination of inputs to validate the user. Generally, you choose 2 or 3 of these:

Something only the user knows (e.g., a password or secret question or both)
Something the user has (e.g., a mobile device, a dongle, or a keycard)
Something that is the user (e.g., a fingerprint, a retinal scan, or a voiceprint)

You can use your API layer to add multifactor authentication to all paths to access your system. We have customers who use APIs to enforce multifactor authentication and sign in to a green screen IBM i session. For example, the user signs on through the standard IBM i green screen signon display, but before they get to the IBM i, the system calls an API that sends a verification message to their phone. They must respond to the message before gaining access to the system.

The API Layer As Your Main Line of Defense

You can set up your system to force all incoming and outbound calls (as well as all green screen sessions described above) to connect via the API layer. That way, you have a central place to monitor all system access. If the API layer supports open source, you can incorporate the latest security and notification modules you need to provide your IBM i with the highest level of protection. So, rather than being a source of risk, your API layer can mitigate your risk.

API Management And Monitoring

To keep your system safe, you need to manage and monitor access. There are several things you can do to reduce risk.

IP address permissions and blocking: You can grant or deny access based on the IP address from which an API request is coming. You can grant access only to known and trusted IP addresses and/or block API access for requests coming from known, bad IP addresses.
Distributed Denial of Service attack blocking: You can be alerted to sudden spikes in API requests by monitoring API activity. The system can notify you immediately as the problem arises and can be configured to automatically throttle the requests if the volume reaches a defined threshold.
Bad request monitoring: Hackers often attempt to discover credentials by sending repeated signon requests. You can monitor this and block a user or IP address automatically after a pre-determined number of failed sign-on requests.

An API Dashboard can make it easy to monitor API activity. You can then take action like throttling or rate-limiting API calls.

Your API can be overwhelmed by call volume intentionally (as an attack on your system) or by accident (customers make mistakes). In either case, the strategy is similar: Monitor, Identify and Manage. You must monitor the traffic coming into your system and watch for unusual patterns. These might be a large sudden spike in traffic from unknown sources (probably an attack) or a large spike in traffic from a particular, known source (probably a user mistake). Once you have identified an issue, you can block the problematic user until they correct the mistake or turn off the API. In the case of an attack, you can adjust the URI for the API and redirect your customers to the new link.

Careful planning and implementing an API strategy can dramatically reduce your risk of a costly breach from either external or internal attacks. There are well-documented steps for setting up secure authentication and authorization in conjunction with a Zero Trust policy. If you would like to drill deeper into any of these topics, please reach out to me (or any of our API security experts at Eradani). I’d love to hear from you!

Daniel Magid is founder and chief executive officer at Eradani.

This content is sponsored by Eradani.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search