Overview
As new technology makes its way to the mainframe, ISVs and corporate IT managers face new challenges when it comes to securing mainframe-based data. Information security threats are increasing from both internal and external sources.
Internally, unauthorized employee access to customer data is increasing due to increased economic pressures. Unsecured corporate data is just too tempting when exposed to those wanting to "turn the easy buck". I always think it is ridiculous when my phone company representative asks if they can access my records. Then, I realize what information they have and that this process is in place to prevent fraudulent internal activity. One representitive went as far as apologizing for asking me for my account number several times recently, as they were not allowed to write it down because someone could dig through the trash and find it.
Externally, offsite data has a knack for falling into the wrong hands. Documents must be shredded before they can be placed into the trash. Hackers have better tools for listening to public internet traffic. I sat at a small conference recently with a sniffer running on my laptop, and picked up 4 or 5 e-mail passwords. For many, a single password is used for banking, investments, and even their e-mail accounts.Think of this the next time you logon for e-mail from your laptop, or iPhone while on the road or your favorite wireless hotspot.
Physical security and network security measures will need to increase as technology evolves. Here are a few areas that need to be addressed in many organizations...
File Security
For years, automatic dataset protection (ADSP) was not available in RACF. Products such as ACF2 have used this as a default (and competitive advantage claim) since product inception. Today, I still find shops where ADSP is not enabled in RCAF. Therefore, any new datasets that are created are not automatically protected as a default. For ISVs, source code and product libraries are potentially available to unauthorized employees or contractors. Although the penalty is stiffer these days, there have been instances of commercial ISVs having their entire source code library posted on a bulletin board. For corporate IT, how much of your customer data is available to programmers & consultants in production datasets, not to mention the lesser controlled test files. Is there a value that can be placed on your source code? Your customer information? Can you ignore the risk and exposure?
Naming standards go a long ways toward making sure sensitive data is secured properly. Security administrators can easily control who can read, write, and control datasets when good naming practices are in use. Good naming standards are also necessary for good catalog management and system managed storage (SMS).
Grouping users into groups eases the nightmare of administering external security software such as RACF, ACF2, and Top-Secret. Once a group is given a proper level of access, members of that group inherit those security rights.
If ADSP is enabled, good naming standards are in place, and an adequate level of grouping users into controlled groups is in place, this forms a minimal level of security to help protect your organization. As every shop is unique in their security requirements, additional controls may be needed.
Client / Server Security
As we tend to have more and more client-server applications deployed on the mainframe, the issue of server security comes into play. Who should have access to the server? Is the application written in a manner that excludes unauthorized access? Many server applications interrogate the incoming IP address to authenticate valid server activity. Others provide a login process to validate the user. Some go as far as doing a RACROUTE check with RACF to validate the "current" status (revoked or not) & password of the incoming connections. This year alone, I have had to add code to several products to address sniffer and denial of service (DoS) attacks on mainframe servers.
Another good practice is to log incoming connections to a server. First, this aids in any short-term diagnosis activities when problems occur. Second, if there is a compromise of data good records help you determine the level of the exposure.
Lastly, unless you have a controlled network where there is no way a person can sniff for packets, client-server communications should be encrypted from the "wandering eye". Secure Socket Layer (SSL) is a quick remedy to this problem. Depending on the information, especially customer data, a strong "standardized" encryption algorithm should be used. ICSF provides a variety of methods to accomplish this process.
Securing Customer Information
Whether in a file, or on the network, encryption of data must increase in the future. Internal and external identity theft is the biggest catalyst for this movement. Regulatory compliance will become mandatory, especially where customer data is present, even for smaller businesses.
We have developed generic encryption routines for several clients in the past few years. One example was to encrypt all credit card information during a DB2 database load. My belief is that AES with 128+ bit compression is the best way to go. I also believe that if you have an ICSF capable processor, building a generic encryption & decryption routine is the way to go when encrypting fields within a file, or an entire packet of network data.
Lastly, secure the usage of your encryption & decryption routine. In ICSF, only the security administrator will know the encryption key offering the maximum in peace of mind. If exchanging information with outside entities, ICSF allows public and private keys that will allow you to share your key with outside parties for the purposes of encrypting your data.
Conclusion
As we innovate on the mainframe, our world is also going to get more complicated. As we design new systems we need to take an extended look at data security. Plan for the worst case scenario, it will cost you far less in the long run.
As always, I encourage your questions and feedback! Please share your insight and experiences, as I know I have only touched the tip of the iceberg here...
Ralph Johnson is the owner and founder of Techsys Software Services LLC, a Dallas based mainframe software consulting firm that specializes in system programming and system software development. Techsys provides development & technical support for over a dozen commercial mainframe software applications.
(ifhxm8tz2j)