Are there security problems with SNA? It is a widely held perception that SNA networks are secure. Despite the rapid adoption of TCP/IP, SNA still lives. The following statistics were taken from the recent Vedacom Corp. article, “SNA and TCP/IP Convergence, a White Paper.”
- The installed base of SNA-based applications and networks is greater than $20 trillion worldwide.
- Ninety percent of the world’s largest enterprises use mainframes with SNA-based applications. Furthermore, 60 to 70 percent of mission- and business-critical applications in U.S. enterprises are SNA-based.
- More than 50 percent of business data traffic, and more than 70 percent of transactions, are SNA-based.
- SNA supports the majority of Online Transaction Processing applications (OLTPs).
- The cost of using Unix or Windows servers in terms of staffing and software significantly increases when going from 96 to 99.999 percent uptime.
It seems likely that this will change only slowly over the next five to 10 years. Therefore, it seems imperative to pay attention to security. Let us tell you about some problems at real user sites over the last few years. Then, you can determine for yourself whether or not you should investigate SNA security on your network, and/or what the price may be if you decide to do nothing.
We have found that the tools to implement security are there but often are not used. In many cases, policies for maintaining a secure network are not strictly regulated, and monitoring is nonexistent. During a recent presentation at the Online Terror and Technology Conference, speaker Dennis McCallam stated that the number one threat to any information system is from insider attack.
We have developed a proprietary security technology that allows us to check all SNA sessions and BIND parameters. During the course of our installations, we ran into the following incidents, which may interest you. By the way, all of these would fall into the classification of insider attack. We also know of several other incidents that were external attacks.
Case 1: Unauthorized Viewing of Client Data
A service bureau data center had two individual banking groups as clients; we will call them Group 1 and Group 2. Because the security algorithms they used for LU6.2 were done incorrectly, Group 2 could view and modify the data from Group 1. The data center did not learn of this problem for a long time. Group 2 kept this information confidential and saw this as a competitive advantage. This changed for Group 1 when they found out that Group 2 was also able to view their information!
Group 2 reacted by complaining to the data center and by requesting compensatory payments against the data center as the service provider. The loss of credibility of the service provider within the community cannot be overstated. To date, their business has not recovered. The provider used RACF on the mainframes, but in this case, the system did not warn anyone nor was the unauthorized group of clients rejected.
Case 2: Free Access to DB2 Data
A data center unknowingly allowed free access to unauthorized users to all data of a core DB2 database. The problem was caused again by invalid security parameter settings for APPC (LU6.2). Was this done by mistake or with full knowledge of the consequences? The staff at the data center did not know of this security problem for almost a year!
The data center provider could not understand what had happened, as it was using RACF. However, in the end, although RACF protected the system, the provider had to admit that it did not have RACF set correctly to coordinate with the network design!