IBM i exit points are designed to make life easier by allowing for increased automation, integration, and security when accessing critical system and application functions. Exit points allow you to call customized code whenever a user accesses a critical IBM I function, such as server logons, FTP transfers, SQL processing, and ODBC requests. Used properly, exit point processing helps protect your IBM i system from outside attackers or internal users trying to access protected data and programs.
However, to truly protect your system, it’s important to understand who is accessing critical IBM i processes via remote servers or exit points, know what actions they are performing, and block unauthorized access.
Stopping hackers at the IBM i doorstep
The Internet has opened up our data to vulnerabilities from remote users performing unauthorized tasks, such as FTPing a file. Using exit point processing also allows the IBM i to track unwanted access to system objects. For example, you can write code to track who is accessing a specific file using an exit point.
But it’s not enough to know that someone is accessing a specific exit point. You also want to prevent unauthorized users from accessing objects or commands they shouldn’t. It’s important to have a solution that prevents someone from taking action inside exit point programming, instead of just reporting on that action. It’s also important to have granularity in determining whether or not the user is executing an authorized action permitted inside exit point programming.
SEA iSecurity Firewall: the gatekeeper
Using a third-party IBM i security package such as SEA’s iSecurity Firewall allows you to build intelligence into your firewall and exit point security by supporting complex security rules. iSecurity Firewall helps stop users from hacking into and exploiting holes in your IBM i security by implementing these four layers of security that help protect your IBM i objects and commands.
- Determining if the user is authorized to a server or its exit points
- Determining whether an IP address or device is allowed to access a server or its exit points
- Determining what actions a user is allowed to perform in a particular exit point (ex., for FTP, are they allowed to perform PUT, GET, SELECT, etc.)
- Determining whether the user is authorized to use the native object they are trying to access BEFORE the system’s native object security is checked
These multiple checks help protect your system from unauthorized access in a much more comprehensive way than you could check by using exit point programming alone.
Who goes where?
Understanding which exit points you need to control better can be difficult without an easy way to view which remote transactions are occurring on the system. iSecurity Firewall provides reports that show you which users are using which exit points and what they are doing. This helps you better understand how vulnerable your system is. By drilling down into the details, you can understand who is accessing which exit points, which methods they are using, and how often they are accessing your system, providing you with a more complete picture of your risk.
Simulation before creating rules
Once you know which exit points and servers are exposing you to the highest risk, you can define security rules for your system and test-drive those rules. With most security solutions, once you turn the solution on, it immediately starts rejecting transactions, which can cause problems when you are still trying to find the right level of control for your system.
iSecurity Firewall offers a simulation mode that allows you to log all of the events that are happening while you are determining your security rules, without rejecting any transactions. This enables you to confidently evaluate and roll out your changes without impacting production. You can also roll out one exit point at a time, allowing you more control over the entire process.
And SQL, too
SQL has become a very popular way for users to retrieve data. Due to the power of SQL, it is also a concern for security. Using SQL, someone can update, insert or delete data with a single statement, which can violate your security policy. iSecurity Firewall allows you to track which SQL statements have been executed and by whom, adding another layer of protection to your IBM i. Since you know exactly what statements have been written, you can easily audit the changes being made to sensitive data. You can also capture and view SQL statements submitted by both remote and local users, protecting against inside and outside abuse of SQL commands.
Beyond exit point security
You can reduce the risk that exit points can cause by implementing a solution like SEA’s iSecurity Firewall to monitor and protect your system from unauthorized access. You can also use iSecurity Firewall’s simulator to test-drive security changes before rolling out each change, a feature that many solutions don’t provide. iSecurity Firewall also provides more granular control over security rules, which prevent unwanted actions from taking place. Solutions like iSecurity Firewall make sure that you can easily track who is accessing your exit points and most importantly, prevent them from being able to perform tasks that put your critical data at risk.67
