While the IBM i is one of the most secure systems in the world, incredible damage can still be incurred from well-meaning but clumsy users who accidentally delete or corrupt data. Given that, let’s look at some of the most common “accidental IBM i hacks” and what you can do about them.
Not ensuring that production data is protected
Ensuring that changes can’t be made directly to production is important to protecting your business. Not just because the hackers can do harm, but because a developer could simply make a mistake. Unfortunately, those types of mistakes can be costly.
When developing without a change management solution or process in place, it can be easy for a programmer to accidentally make a change to production data while thinking they are in the development environment. IT often is forced to multi-task in order to keep things running efficiently, and a distracted developer may have multiple connections open at once. Many developers have found themselves in hot water when they realize that they just made a change to the production environment, when they thought they were in test. While in many cases, this works out fine, there are other times when that mistake is costly. If the developer does a test and thinks they are in the development area and they decide to clean up the data, they might just wipe out the production data set without realizing it. No malice was intended but the result is a mess to clean up and potential lost data for the business.
FTP access with too much authority
Another area where companies can experience trouble is with data corruption. While it’s true a hacker can do damage to your data, it’s often employees who make mistakes that cause the problems. Having the ability to FTP a file can be really useful to business. It eliminates the need to have someone perform data entry and decreases bad data from being typed in manually. It also can be an exposure to your business. If a user downloads a file from your IBM i and they have the authority to change that file, you could have bad data accidentally uploaded. If some of the rows are deleted or the wrong file is uploaded, all of that data can be lost.
Incorrectly responding to critical Jobs
Nightly batch processes are common in the IBM i community. These nightly batch jobs often include processing data, updating inventory, creating invoices, and generating reports. If this processing is not done correctly, it can affect users and cause a lot of problems for the business. Critical jobs that update data and ensure that the business is ready for a new day are run in succession. One job affects how the next job runs or whether or not it runs at all. If a job fails and it is not restarted correctly it can negatively affect the jobs that are supposed to run after it. The result of this can require a lot of manual work to get the data back to the state it should be in.
Ignoring critical system message
Ignoring system messages can result in disaster! QSYSOPR collects a lot of information and it can be difficult to manually read through the log to determine what is critical and needs a response. Log files and audit journals can create a large amount of data, which can fill up disk space without you noticing it. If you ignore critical system messages you could find yourself out of disk space. It’s better to manage these things as you go, so you don’t unexpectedly find yourself with an issue.
Remote access
Allowing employees to access your system from wherever they are is helpful for the business and the employee. It can also expose you to risks. Having the wrong DNS or using an incorrect IP address can wreak havoc. This is especially risky when companies use high availability and preform role swaps. A well-meaning employee could not realize that they are connected to the production environment and perform some tasks that could affect the business, such as making a code change in production that causes a problem or deleting datasets that they thought were in test to find it was the production data.
Protect your business from accidents
The good news is that all of these issues can be avoided with improved security controls.
Here are five ways you can prevent these “accidental IBM i attacks” from harming your system.
- Most of these accidents can be avoided by eliminating excess user authorities especially for programming staff, and putting tighter object level security in place. Tying down your production system security is the key to securing your data and applications.
- Use a change management solution to insure that new production data is reviewed and appropriately promoted from development to production. Don’t allow programmers to make untested changes directly to production code.
- Limit access to IBM i utilities that can change data outside of your programming environment, such as FTP, SQL, and Data File Utility (DFU).
- Use IBM i message and resource monitoring software to detect and alert on-call responders to issues (inquiry messages, resource issues, jobs out of control, etc.) in real time, and reduce the risk to the business.
- Control batch jobs through job schedulers and message resource monitoring software. Job schedulers help ensure that jobs are all started on time and message monitoring can help ensure that they complete as expected. Message monitoring can alert on-call responders when an error occurs, while job schedulers can be configured to prevent a particular job stream from completing if any of its’ component jobs are in error or didn’t finish, giving responders time to correct the issue before it can cause additional harm.
Even when you don’t have to comply with regulations, it’s important to follow best practices for security to protect your business and your data. With good security practices, you can help ensure that your employees can’t make these types of mistakes. We’re all human and we make mistakes, so putting in place good controls can help protect your business.
Not sure where to start? SEA can offer you a no-cost IBM i security assessment to determine which of these risks you face (and more) and provide you with solutions to prevent them from happening.
