Howard2nd   0 pts.  |   May 25 2005  10:51AM GMT

According to NSA the only un-hackable computer is one with no outside connections and no physical access. Any misuse is then defined not as a hack but operator mis/malfeance.

That said, I use ODBC a lot. ODBC is a conduit. It can be a secure confuit, but usually isn’t. Security for data and databases has three parts - security of the database server, security of the client on the user system, and security of the conduit. DB2, Infomix, Oracle, Sql Server all support encrypted connections - PKI certificates for server and every client and the conduit is secure. Access to the conduit is another matter.
DB programming is remarkably consistent about one thing. You set up one user for the database with insert/update rights and one password then all the clients use the same user/pswd for their connections. Or you spend every hour of your job ‘fixing user passwords’. The DB administrator(s) won’t put up with that and you get one user/one password. Now we have two factors of security in place - encrypted conduit and user/pswd for DB access. The third part is on the client, every user has a separate account with the password as complicated as you wish and they will tolerate. Plus they have a different account/password for system login. And if you have followed best practice in client design their are fileds to record last modification user, date, and time.

Now the great example of database hacking was “Slammer” a worm targeted against SQL Server. It did NOT arrive by ODBC, but directly against the known connection port (1433/1434) and took advantage of excreble installation pratices. Installing a database on a server with the SA (System Administrator) password left blank. Now before you jump down the network/database admin throat, consider my case. The only incidence of ’slammer’ I had was during an update to McAfee eOrchestrator (enterprise anti-virus). They used the MSDE (Desktop Engine) which installed silently and reguired a registry hack to set the SA password.

Is any computer hackable? YES! Are all at equal risk? NO!
You keep your PC’s clean and don’t lose sleep over the AS/400. It is not a big target in hackerdom.

Good Luck.

bobkberg   895 pts.  |   May 25 2005  11:18AM GMT

I don’t usually get into anything related to iSeries/AS400, but in this case….
As others have already pointed out, it’s achievable.

My point (painfully learned, I might add) is that if upper management doesn’t give SERIOUS support to overall security, (including holding vendors accountable) then you’re not likely to achieve any significant improvements.

Bob

Michont   25 pts.  |   May 25 2005  11:41AM GMT

Virus infections on os/400 (or comparable) aren’t something we see, though the IFS can be prone to certain things. Thing is, not too many hackers can afford to get the code to create viruses for the system, which is a good thing. Now, as far as security goes with ODBC, SQL and FTP, we use Powerlock and haven’t had any issues. We have Messenger Plus inform us when someone tries to get into the system (like a programmer) and doesn’t have the authority to do it. I trust the iSeries or AS400 in these issues over Microsoft.

kholder   0 pts.  |   May 25 2005  12:22PM GMT

I manage a fairly good size AS/400 and we use ODBC/JDBC. The AS/400 uses system level security to allow updates to the database objects via ODBC. With that said, if you setup security correctly then you have little to worry about. If you still worry about access with ODBC then look at your audit and application journals. If you aren?t sure if all of your application can be secured at the object level, then I would strongly suggest that you look for a third party exit point product. The product we use can swap profiles to a profile with no access at all to the system to one that has all access. It can generate reports of the access for FTP, Telnet, ODBC and more. We too use PowerLock.

It is true (to the best of my knowledge) that the AS/400 or iSeries has not had a virus. It can however host viruses in the IFS. If you have antivirus software at the PC and at the email level then this should not be a problem.

The AS/400/iSeries can be very secure but 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. <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/index.htm?info/rzatz/51/sec/isecref.htm" title="http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/index.htm?info/rzatz/51/sec/isecref.htm" target="_blank">http://publib.boulder.ibm.com/infocenter…</a>
We also have upper managements support now with required SOX compliance. I don?t think they want to go to jail if they ignore any security issues.

I would also recommend that all access from outside your network only be allowed with a secure encrypted VPN connection.

ColinNZ   0 pts.  |   May 26 2005  4:46AM GMT

Thank you all!
You’ve given us some good ideas/products to investigate.
Very much appreciated!
I have to admit that the ODBC issue caught us by supprise. We had expected the JDE database security to be enforced.
Most of our ODBC connections require read-only access so we’ve configured them to be read-ony at the client end. Not ideal, however we had problems securing things at the AS400 end.
While this gives us an illusion of security - it doesn’t cater for the wayward user with some knowledge of AS400 and ODBC.

Thank you again for your explanations & suggestions!

Juvencio   0 pts.  |   May 26 2005  8:23AM GMT

I belive it al depends in the intentions. Exe files from a pc will not do a thing within the as/400, but then, there are a lot of security issues depending on your site practices. In the past, I had used “workarounds” within erp packages in order to access administration functions, I once bumped into a user/password “trap” program, and in the “beginning”: how about IBM’s practice of providing system profiles with password similar to the profile? (Of course qsecofr was changed but must installations didn’t knew of qpgmr) - thanks God IBM improved that issue. Adopting authorities, attention handling programs, they all represent security issues. But again, tight security policies is all you need.

apothen   0 pts.  |   May 26 2005  9:15AM GMT

A valid logon does not gurantee you access to anything on the AS/400 if you have the security setup right. If I am not mistaken, DB2/400 allows you to set up security even at raw 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.

Having said that, if a hacker manages to break into a window’s PC of a power user who has a live connection to the 400, I am not sure what good the the AS/400 security.

Check out the website for <a href="http://www.bytware.com" title="http://www.bytware.com" target="_blank">http://www.bytware.com</a>
They seem to sell software and services related to AS/400 security

AP

TomLiotta   7355 pts.  |   May 26 2005  2:50PM GMT

Yes, an average AS/400 (or iSeries) is “hackable”.

And no, an AS/400 (or iSeries) that has proper security settings is not hackable.

You must differentiate between the security facilities that are provided with OS/400 and those facilities that are used by AS/400 administrators and applications. I have never reviewed JDE/OneWorld, so I can’t comment on it; but I know how such _applications_ are commonly “secured” and they commonly do so in a way that circumvents the scheme that IBM supplied with OS/400. The result is often that network access such as through ODBC is far too open.

That problem goes back to the time before the internet, and even LANs as we know them today, had routes that reached most companies’ AS/400. Because there was no network access, applications only used security facilities that were appropriate for direct terminal access. As long as you logged in through a terminal, you could only run the programs that were made available to you at the terminal. Security was applied only within the programs themselves.

At that time, there was essentially no problem.

Then comes the big TCP/IP explosion and Windows and Windows Network Neighborhood and the internet, and everybody clamored for network/LAN/internet access. But _nobody_ wanted to fund changes to the applications to bring their security in line with the new access paradigm.

There’s the current problem as short as I can make it.

Two general alternatives to achieve significant security:

1) By far the most important would be to set correct object-based security and to assign correct roles to users.

2) Since (1) is well outside the budget for most companies, the creation and/or use of exit programs registered against your network access exit points can provide needed security elements.

Disclaimer: I work for PowerTech, a vendor of such exit programs, e.g., PowerLock NetworkSecurity.

However, even we at PowerTech believe in option (1). If you install any of our products, you’ll find a strong object- and capability-based security scheme applied to product objects and product users. We’re probably not perfect, but we’re pretty comfortable that our product databases are _not_ going to be updated through ODBC even by authorized product users. (Of course, a user with *ALLOBJ or similar authority is able to do anything on their own machine — all bets are off against *ALLOBJ, etc.)

The point is that it simply isn’t true that access through ODBC “completely bypass any AS400 security restrictions” nor that it happens “with NO AUDIT TRAIL”. Even an *ALLOBJ user who does alter our database via ODBC (or DDM or Client Access file transfer or Windows Network shares or any other access) will leave a clear audit trail. That will be true whether you activate our exit programs on your machine or not. It’s true simply because we write our products according to OS/400 principles.

It isn’t that ODBC bypasses AS/400 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.

If these are issues that concern you, then perhaps a product such as ours is a good solution. It’s also possible to write your own exit programs — IBM supplies examples in the TCP/IP and host servers guides; you can pretty much copy/paste into a source member to get started. (Obviously there are potential pitfalls otherwise there wouldn’t be a market for us, but I did it before working here.)

It’s also possible simply to set security on where it’s needed. And it is simple — it’s just that it’s simple for so many objects and types that there’s a huge volume.

Good luck.

solutions1   0 pts.  |   May 26 2005  8:08PM GMT

Your definition of hack - “unauthorized changes to data” - is perhaps too oriented toward vandalism while ignoring theft and other forms of misappropriation. A lot of AS/400s are employed in tasks and industries far too mundane to interest to the hacker community, and very few would actually want to own one to develop viruses. On the other hand, companies run sensitive business processes on AS/400s, and it is insiders and former insiders who know the value of the data and, perhaps, how to get to it. People who misappropriate data are not likely to vandalize it, which leaves tracks, so they can be more insidious than a vandal.

solutions1   0 pts.  |   May 26 2005  8:08PM GMT

Your definition of hack - “unauthorized changes to data” - is perhaps too oriented toward vandalism while ignoring theft and other forms of misappropriation. A lot of AS/400s are employed in tasks and industries far too mundane to interest to the hacker community, and very few would actually want to own one to develop viruses. On the other hand, companies run sensitive business processes on AS/400s, and it is insiders and former insiders who know the value of the data and, perhaps, how to get to it. People who misappropriate data are not likely to vandalize it, which leaves tracks, so they can be more insidious than a vandal.

apothen   0 pts.  |   May 27 2005  9:38AM GMT

Check out this article from Iseriesnews this month.

 <a href="http://www.iseriesnetwork.com/artarchive/index.cfm?fuseaction=viewarticle&CO_ContentID=20119&channel=&subart=" title="http://www.iseriesnetwork.com/artarchive/index.cfm?fuseaction=viewarticle&CO_ContentID=20119&channel=&subart=" target="_blank">http://www.iseriesnetwork.com/artarchive…</a>

Directs you to a lot of good places on the net that has information on iseries security.

AP

AuditiSeries   0 pts.  |   May 31 2005  10:56AM GMT

You’ve defintely received alot of good direction towards solving your problem. Especially at the OS level.

I noticed you mentioned “no audit trails” which is true at the database level. However there are third party solutions that address this need. There are also journal based reporting solutions, like LiveAudit, that give visibility into database activity, though not everyone likes to journal. One that I’ve worked with before, called DataThread, let’s you decide the method of tracking changes. It provides the kind of audit trail your looking for as well, at the record & field level, regardless of access method. It also has data surveillance capability. I found their link on the web, hope this helps.

 <a href="http://www.innovatum.com/datathread.php" title="http://www.innovatum.com/datathread.php" target="_blank">http://www.innovatum.com/datathread.php</a>

Good luck!

JeffJAG   0 pts.  |   May 31 2005  6:35PM GMT

OS/400 object-level authorities have to be satisfied regardless of the method of access (5250, telnet, ftp, ODBC, etc.).

It is not true that a user once connected to the AS/400 via ODBC can bypass OS/400 security and “have full read/write access to change anything in any database table on the AS400″ unless that user has been granted object authority to those database files or that user has *ALLOBJ special authority thereby making him a security officer-class user (i.e. “root” in *nix-speak).

That, however, is exactly what goes on in some sites who depend on green screen “menu security”. In the past, users were given way to much authority, then their actions on a 5250 “green screen” terminal session were controlled by the options given them on their initial menu. This method was inherited from the System/38 and was a very common method when the only method of access was via twin-ax connected dumb terminals.

Menu “security” is not security any longer because there are miriad ways of connecting to the AS/400, ODBC being only one of them.

Check your user authorities to your database files. From your description, I would say that they have at least *CHANGE if not *ALL authority to the files in question.

(This also assumes that your QSECURITY system value is set to 30 or 40. If it is set to 20 or 10, then OS/400 does no object authority checking at all.)

imigrnt   0 pts.  |   May 31 2005  11:23PM GMT

With all of the seriousness of the security issues being discussed here, I wanted to start by lightening the mood a little and point you to one of the audit product websites discussed in one thread … who (on their main product page) describes their product as “DataThread, the mulit-award winning software from Innovatum …” Is that as in Mullet-winning? I had visions of ‘Joe Dirt’ in charge of securing my system!!

Anyway, more seriously, it sounds like your shop is a little starved for some good AS/400 (a.k.a iSeries) security knoweldge. Don’t feel lonely as the administrators that *really* understand the nuances of security on the platform are few and far between. As such, it is even more critical to employ the kind of 3rd party products you have seen referred to in order to fill the control and audit voids left in most implementations of the base OS.

I *do* have a pretty strong knowledge of OS/400 security and make a living doing assessments etc. and can tell you that you will probably not learn to truly secure your system at the object level overnight. As such, I can’t empahsize enough the advantage of using a tool like PowerTech’s NetworkSecurity that places an application front end on the network access issues. It is not a silver bullet in that your 5250 (green screen access) still needs to be probably secured, but it is a *huge* step in the right direction.

One thing that I recently discovered is that at V5R3, the FTP and DDM servers again do NOT (I repeat do NOT) appear to enforce the limit capability setting when running a remote command!! It is MISSION CRITICAL that you control these exits or (not usually very viable) shut down the servers that allow them.

I know for one, that PowerTech  <a href="http://www.powertech.com" title="http://www.powertech.(" target="_blank">www.powertech.com</a>) can do a nice (and $0 I believe) audit of your system. They call it a FlashAudit and I have all of my customers run one to see where they stand and give them great management justification for additional funding (we can always use that right?). From there, a web demo can show you how easily you can secure your system.

Beyond that, the definitive security book (other than IBMs Security Reference) is by Carol Woodbury  <a href="http://mc-store.com/mcpressonline/5841.html" title="http://mc-store.com/mcpressonline/5841.html" target="_blank">http://mc-store.com/mcpressonline/5841.h…</a>).

Due to the seriousness of not doing this right, my best recommendation to AS/400 lightweights is … find an reputable expert to help you!! (ahem, ping me if you need help find one! heehee)

Good Luck!

Robin

AuditiSeries   0 pts.  |   Jun 1 2005  10:01AM GMT

Securing one object is easy enough for any adminstrator or consultant worth their weight. If that object contains millions of records accessed by hundreds of users, that’s where the gap exists. The majority of fraud is performed by users who have authorized access to the data. Therefore, having visibilty into the activity at the record and field level of what users are adding, changing and deleting is another opportunity where you can bring real value to your enterprise.

Many OS administrators aren’t familiar with the workings of databases from an application standpoint, hence they can be defensive about solving issues that they don’t fully understand, or know how to address.

Monitoring business data in addition to your OS will give you an advantage, especially if you can integrate and automate your audit controls into the database. I hope you consider both during your undertaking for your own benefit and avoid being corralled by one advisor who wants to introduce you to their billable services or product they sell.

On a funnier note, anyone who is more interested in using a typo on a website for derogatory purposes instead of recognizing(which they obviously don’t) the true benefits a technology may offer you, probably has another agenda for you and your wallet! Good luck Colin!

pabila   0 pts.  |   Jun 29 2005  10:15AM GMT

Virus and Hacker are two different peas, although generally related to be in the same pod.
A virus by nature will not run on the ISeries as does on Windows/Unix… OS’s. Yes ISeries can be LPAR’d to share IFS. IF YOUR SYSTEM (ISeries) is correctly configured (user access), the user with access to the ISeries, via PC, would only have rights to certain objects. A hacker could have access to these objects and generally are files conducive to PC applications/files…not ISeries (core) files (as the PC world would say).
I’ve had users (as always the culprits) circumventing the system (ISeries) either database or procedures but with proper auditing, these were caught/minimized and corrected.
YOUR ISeries administrator has to be vigilant to place additional ‘check’ parameters in place when it comes to access and exit points to the ISeries. (This includes authorized users who may inadvertantly be authorized to change data within an object/database?)
IBM has placed authorization/access from user level down to the file/object. PARANOA has to be part of the process of ‘adminitering’ the ISeries?

RashmiSham   0 pts.  |   Nov 27 2007  11:21AM GMT

I can’t believe that all of you missed the most important point when talking about the reason why iSeries is consider unhackable.. all the CERT staff are not goonies, they know the reason behind.. which is different data format - iSeries talk in EBCDIC while PC and Unix based is in ASCII so when you wrote virus programs or using hacking tool to try to intrude into iseries environment, you could only reach first level which is maybe storing the virus in IFS environment but it will stay there forever..ever until it is removed by admin.

Now, you could put it in IFS BUT provided it is being shared (setting the access rights properly) and mapped to your logical drive otherwise you can kiss your *** goodbye trying to store the virus in it.

V5R3 onwards, IBM has enforce more security features and some of this security values is mandatory to OS level such as security system values. If it is configure and setup properly, nothing can get penetrated in that level by just increasing the OS security level from 30 to 40 or 50 (C2 level).

Furthermore, Bytware Inc. has release an native OS400 anti virus product that will monitor IFS environment.

Frankly speaking, his three argument points indicate clearly that he do not know much about AS400 environment so he should not make baseless statement without proper facts. My advise to him is to do proper groundwork before putting up this sort of statement.

Anyway, I don’t blame ColinNZ since he has no AS400 background.

My motto is “Everything and Anything is hackable unless it is managed”

Self-Intro:
I’m a trained Certified Ethical Hacker and I’m also an 16 years AS400 experience background (a.k.a iSeries, System i). Right now, trying to write encryption and intrusion detection tool for OS400 during my free times.