Perhaps there is also an issue of availability. Windows, linux, bsd, etc. are cheap or free, so the barrier to entry to obtaining supervisor state (root) is very low. Everyone is the administrator on their own system. Whereas, the barriers to entry for getting a zOS system where you have the ability to actually switch to supervisor state is rather high. Hercules and pirated copies of zOS are reducing this somewhat, but there is is an education curve.
Another factor is the limited number target systems when you compare the zOS system installed base on a worldwide basis to the number of previously mentioned system. Just based on shear numbers, it is much more likely to find an 'open' windows, Linux, etc., system than a zOS system. That combined with the fact that zOS and related systems have always had much stricter installation process makes them less likely to be successfully attached with by a virus. There is also an almost unlimited amount of ISV software for windows, linux, etc. of unknown quality and authorship. This also combines with the other factors to make it that much easier to place viruses on these machines. While theoretically possible, it seems like a there is a low probability for a zOS virus to show up in the field. The other attack vectors still hold: insider damage, non-virus attack (DOS on a zOS based website), etc. can still occur. But these are a different, but related, issue. Mon, Jan 31, 2011 at 10:53 AM, Scott Ford <scott_j_f...@yahoo.com> wrote: > I can believe auditors would ask a question like , virus checking on > mainframes, > been doing systems work on mainframes 40+ yrs, never seen a virus AT ALL.. > On a PC totally different issue, btw I think one of the reason you dont see > viruses on mainframes because of the difficulty required to write one IMHO > .. > > Scott J Ford > > > > > > ________________________________ > From: Clark Morris <cfmpub...@ns.sympatico.ca> > To: IBM-MAIN@bama.ua.edu > Sent: Sun, January 30, 2011 2:05:47 PM > Subject: Re: z/OS Virus Checker & zLinux Virus Checker > > On 28 Jan 2011 15:21:24 -0800, in bit.listserv.ibm-main you wrote: > > >I too have auditors who treat the my mainframe like one those little > puters and > >I find it best to first educate them before they convince my management to > send > >me chasing phantoms. Don't assume your auditor won't appreciate a > mainframe > >education. > > > >The first place to hide a virus is in the OS, y/n? What protects the > mainframe > >OS? Answer, APF. I monitor the APF libraries for any alterations on a > daily > >basis. Any changes that didn't go thru change control are cause for > >investigation. Most auditors don't know squat about APF, and if they did, > they > >would be asking about it instead of a mainframe virus scanner. > > > > > >The 2nd place to hide virus is in software, which on the mainframe are the > >command libraries. Aside from the potential for corrupt vendor software > >(unlikely a vendor will install compromised loadlib, but we're talking > auditors > >here), most those command libraries (vendor & in-house) are written in > >interpretive languages and can be scanned using standard PDS utilities for > >whatever string (like delete commands) your shop believes poses the > greatest > >threat. Loadlibs can be scanned using standard utilities as well. One > method > >is to unload the PDS to a GDG daily, and compare the current to the > previous > >day's file for any changes. Start with the linklist and the logon proc > >sysproc/sysexec allocations, after that the catalog can be scanned for > >application and personal clist/rexx libraries. Looking for changes to the > >baseline may not qualify as a virus scanner, but it's a whole lot better > than > >doing nothing or spending a fortune on unnecessary software. > > > > If there is a virus, Trojan etc. that affects web servers such as > Eclipse, then that server on zOS may be vulnerable. A virus, worm, > etc. designed to execute Intel code won't be much of a problem but > code designed to execute Java code could be. The question is what > applications are running that communicate with the world at large > (online banking, online ordering, etc.) and what are their > vulnerabilities. Can SQL injection work against DB2? > > Clark Morris > > > >The 3rd place I look for mainframe malware is in the parmlibs, JCL, > macros, > >utilities and such. DASD utilities can erase the entire storage pool if > >corrupted. Who can update these libraries? Are they subject to stringent > >change control procedures? Are their contents monitored for changes and > >content? Does your auditor know what DASD is? HSM? DFDSS? > > > > > >Address these items and I can almost guarantee that you'll pass your > audits like > >I do. > > > > > >Disclaimer: apart from monitoring APF, none the above is industry > standard, not > >yet anyway... > > > > > > > >-hernandez > > > > > > > >> > >> > >> On Fri, 28 Jan 2011 12:27:54 -0600, Jim Marshall <jim.marsh...@opm.gov> > >> wrote: > >> > >> >Auditors came around and wrote up our z/OS V1R10 > >> Sysplex for not running a > >> >Virus Checker. Anyone has a constructive solution > >> as to one being available or > >> >some verbage which defends the position. > >> > > >> >Been hunting around for a Virus Checker for > >> zLinux. Also interested in what > >> >kind of over head it might use. > >> > > >> >thanks jim > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access > >> instructions, > >> send email to lists...@bama.ua.edu > >> with the message: GET IBM-MAIN INFO > >> Search the archives at http://bama.ua.edu/archives/ibm-main.html > >> > > > > > > > > > >---------------------------------------------------------------------- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > >Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
