I guess last month's column struck a nerve. Let me be clear: the whole thing was a childish joke. I would not attempt or encourage anyone to perform any of those jokes. I must say, however, I was a little surprised no-one took me to task for a couple of the more far-fetched ones (e.g., dummying out a database archive dataset).
As editor Matt Stansberry pointed out, what we really need is a discussion of mainframe vulnerabilities and what various shops have done to avoid them. Therefore, I invite readers to add their own observations to this column.
User authentication
The mainframe seems to have a better handle on user authentication than other platforms. Whether a datacenter uses Top Secret or Resource Access Control Facility (RACF), a hacker won't get anywhere without a valid ID and maybe a password. However, there are still some problem areas, such as:
A shop must also be careful with control cards for batch jobs using File Transfer Protocol (FTP) or TELNET. These control cards often contain logon ID's and passwords in clear text. Worse, there are similar jobs on Windows and UNIX containing host logon ID's and passwords. This means the control cards must be jealously protected on all the concerned computers.
But, my favorite gotcha is the fact that passwords on 3270 sessions go over the network in clear text. Sniffer trace, anyone?
System datasets
Most shops had this one figured out long ago. The person who can update SYS1.PARMLIB has the keys to the kingdom. The same goes for every parameter library of important subsystems. Then there are APF authorized libraries where a properly linked program has the power to change system control blocks or storage. Most installations do a good job of limiting access to APF libraries, but auditors are always on the lookout for the one improperly defended library some systems programmers keep to the side to be able to slip an authorized program into production "just in case."
Access to dat
To continue reading for free, register below or login
To read more you must become a member of SearchDataCenter.com
abase image copies and logs should be restricted as well. The data may be hard to read without the proper utility but a persistent hacker may be able to get enough information from these sequential files to do some damage. Dataset utilities, such as Hierarchical Storage Manager (DFHSM) and Data Facility Dataset Services (DFDSS) must be secured so that no-one can restore a restricted file under his or her own ID.
Care should be taken to ensure confidential information doesn't end up in personal or globally accessible datasets. It's tempting to take a quick backup of the PIN database under your ID but you must be very careful to delete it later.
The disgruntled employee
Unless the "thought police" work at your company, this has got to be the hardest thing to defend against. After all, the employee got all the access needed to do the job when he or she was perfectly happy. Then something happened that caused the same employee to want to do harm to the company – and other employees may or may not know about it. If you're lucky to get two-weeks notice from the unhappy worker, then I recommend a policy followed at a former employer: As soon as a technical employee gave notice they were released immediately in exchange for additional paid vacation.
Denial of service attacks and other vulnerabilities
We think mainframes are a little less vulnerable to denial of service (DoS) attacks, but the opportunities are still there:
Improperly managed consoles may leave powerful commands available to people who shouldn't use them. For consoles you have to think about physical security too. Finally, the latest hardware provides a Web interface to the hardware maintenance console (HMC) which must be protected.
Some popular monitors (e.g. Omegamon or Mainview) have powerful facilities allowing one to zap storage or kill tasks. A shop needs to ensure these facilities are locked down tightly with access give to those who need and know how to use them.
Preventive action rather than reaction
I hope this column encourages the same amount of discussion as last month's. Let me state that I am a mainframe bigot who thinks few, if any, other platforms can match the big iron for security, reliability and performance. However, I also think pretending the mainframe doesn't have problems is foolish in the extreme. Hiding them won't get the problems fixed and it easier to defend your infrastructure when you have answers to other people's objections.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
Did you find this helpful? Write to Matt Stansberry about your data center concerns at mstansberry@techtarget.com.
