ITKnowledge Exchange user ColinNZ ran into a problem with his iSeries. ColinNZ, an admitted "Windows/Linux" guy, had heard about how the iSeries was "unhackable," but his experiences were not confirming this belief.
ColinNZ is a Windows administrator whose PCs were connecting to an iSeries. He claimed that because of this connection, if Windows was vulnerable then so was the iSeries.
Here's his argument:
1. iSeries client programs for Windows are often written with total disregard to Windows security (i.e. back in the Windows 98 non-secure mentality). Programs such as JD Edwards' OneWorld, which unless butchered, require the end user to be an administrator of his PC. This is a really BAD thing.
2. It is possible to share iSeries disk space as though it were a Windows share. You can't trust the Windows machines, so how can you say that this is secure?
3. ODBC connections? (Please tell me we have our iSeries misconfigured!) A recent audit showed that ODBC connections into the iSeries completely bypass any iSeries security restrictions. That means if the ODBC user has a valid log-on, then he has full read/write access to change anything in any database table on the iSeries, with NO audit trail.
ColinNZ turned to the ITKnowledge Exchange for help on his ODBC security problem.
The consensus among respondents was that the ability to secure the iSeries is available but not always utilized. "Your concerns about security on your iSeries are valid. While it can be a very secure system, many administrators can't or won't take advantage of the ability of OS/400 to secure their data," wrote user nblattner.
User TomLiotta agreed with that contention. "You must differentiate between the security facilities that are provided with OS/400 and those facilities that are used by iSeries administrators and applications," he wrote.
The blame did not lie solely with lazy administrators, though, according to nblattner. "Part of the problem is that most application vendors (JDE included) do a poor job of securing their applications. They use their application's menu system to protect the data but don't do anything about access that bypasses the menu system such as ODBC, FTP, or other network accesses," he wrote.
Both users agreed that using exit point programs could solve ColinNZ's ODBC problem. "You can create an exit program that controls access to the server and limit who should be using it," wrote nblattner.
TomLiotta agreed. "The creation and/or use of exit programs registered against your network access exit points can provide needed security elements," he wrote.
Of course users also said native iSeries security mechanisms could help better secure ColinNZ's iSeries connections if properly implemented. TomLiotta took issue with the possibility that ODBC could circumvent the audit trail. "It isn't that ODBC bypasses iSeries security -- it's that you have security turned off for network access. It isn't that there is no audit trail -- it's that you have audit turned off," he wrote.
Users stressed the object-level security available from OS/400. "If I am not mistaken, DB2/400 allows you to set up security even at row- or column-level security. I would imagine even if you were to use the basic object-level security implemented, you could prevent unauthorized users from updating or deleting the data," wrote ITKE user apothem.
Users suggested that the level of security needed to solve ColinNZ's problems is available online. "The AS/400/iSeries can be very secure but [it] doesn't happen by default. It takes some work to get there like all systems do. Look at this link for more information on securing your system," offered kholder.
Read more of this discussion or join the thread yourself at the ITKnowledge Exchange.
