View Full Version : Mainframe/AS400 Best Practice
El_Luke
03-20-2007, 06:52 AM
For companies that use one server for everything, such as a mainframe or AS400, I would like some clarification. So let's assume that card data is stored on such a system and so the system is obviously in scope. One of the goals is to reduce the scope of systems that PCI affects, which would mean it would be best to segregate that mainframe/AS400 from the main internal network.
However, I have not yet come across a company with an AS400 or mainframe that didn't use it for 50 other things, and didn't have it reside internally and fully accessible. I'm not even sure such a system that is used so extensively can be segmented off.
What is the recommendation for a client with a mainframe or AS/400? Do you see clients choosing to leave the server as is and deal with the larger scope or do you see them segmenting it differently?
lyalc
03-20-2007, 12:21 PM
I'm not that familiar with AS/400, but IBM mainframes (if this is the brand in use) are usually partitioned in to LPARs - logical partitions. In a robust virtual machine environment, such as z/OS, there is very strong seperation or resources (memory, disk etc) between LPARs and they can usually be considered individual servers.
Having 5, 10 or more LPARs is nothing for a mainframe, allowing them to be allocated to dev, test and production web, app and db functionality, or some suitable mix can be implemented to meet the 'primary function per server' , DMZ and 'seperate Db tier' PC requirements is possible.
The auditors role is to ensure that the configured logical servers and the overall environment meet PCI.
Lyal
jbhall56
03-22-2007, 04:16 AM
With IBM mainframe LPARs (zSeries) you do have to look at the configuration of inter-partition communications which allows LPARs to communicate between themselves without using TCP/IP or other, more familiar, communication methods.
Another IBM OS, zVM allows a software virtual machine solution and may also be used in conjunction with LPARing the mainframe. zVM's security is also very robust as are its controls over inter-VM communications.
In regards to the AS/400, now known as the iSeries, they too can be partitioned similar to a mainframe. However, this is not a common practice for most iSeries installations. You will typically see iSeries partitioning with the largest models such as the 570 and 595 or the older 800 series models.
Be aware that both the zSeries and iSeries can be configured with Unix-like consoles. I have seen IT auditors mistake these as Unix systems when the actual underlying OS was not Unix or a Unix derivative.
Also, the zSeries can run Linux natively, so unless the systems programmer explicitly tells you that they are running zOS, MVS or other legacy OS, you may have an entirely different situation. Linux on a zSeries is no different than Linux on any other platform.
That said, most mainframe systems from IBM and Unisys (excluding their Unix product offerings) running legacy OSes such as zOS, zVSE or MCP have very robust security mechanisms in place. Even if they are not logically partitioned, the processing structure does not readily lend itself to inter-region communication without some significant effort. So, just because a system is not LPARed does not mean that it is not secure.
mdahn
03-24-2007, 09:06 PM
I agree with many of the comments made here. You need to take a look at partitioning the access with LPARs and within each application with RACF. Examine how you can reduce access rights within the application or the operating system.
Also examine if someone has access to the OS or just the application. Within the applicaiton do they have access to the full PAN or just a masked PAN? Each of these items will play a role in compliance.
El_Luke
11-01-2007, 07:25 AM
Follow up question to this for those who know AS400's relating to network segmentation.
Let's say a small company has 1 AS400. It has various LPAR's, including one for the card processing/storage/etc. Now the card processing apps need to reach it, but various other people, systems, etc need to hit the other LPAR's on it as well. From a network segmentation standpoint, what are the best options for PCI compliance?
In AS400 land, can different LPARs be given different NIC's and thus different IPs? That would be easiest.
Or assuming the AS400 has a single NIC and IP, where should the server sit, on the internal server network or on the card processing segment?
jbhall56
11-04-2007, 03:56 PM
Even with only one NIC, you can multi-home the AS/400-iSeries NIC with multiple IP addresses assigned to each instance. However, unlike multi-homing in the Windows or Linux world, on the AS/400-iSeries, there is almost no risk of abuse because of the way the telecom software is architected on the AS/400-iSeries. Each virtual NIC can be assigned to an AS/400-iSeries region, thus segmenting the network at the AS/400-iSeries.
However, this also means that your AS/400-iSeries networking capability becomes key to your network segmentation because all traffic for the other users will cross the same wire to get to the server. Therefore, you will want the AS/400-iSeries on its own switch so that you can re-isolate the network traffic to their own VLANs.
lyalc
11-04-2007, 07:43 PM
Note, in my limited experience:
"Each virtual NIC can be assigned to an AS/400-iSeries region, thus segmenting the network at the AS/400-iSeries."
either does not work or is complex to operate on a mainframe/z series that is already integrated into the production processing flow.
z/OS has an internal virtual router (part of Communications Server, I seem to recall) that lets all NICs get traffic to an address bound on that NIC even it if came via another NIC - i.e. there is internal packet forwarding.
One solution is to segment VLANs to each physical NIC, and or apply ACLs/firewalls on the traffic to individual segments/NICs.
jbhall56
11-05-2007, 01:42 PM
I was not referring to the zSeries, only the iSeries-AS/400.
You are correct about the zSeries as IP in zOS, zVM and zVSE is not really a part of traditional VTAM that would run all of the other protocols such as BiSync, SNA, SDLC, etc.
vBulletin® v3.7.4, Copyright ©2000-2010, Jelsoft Enterprises Ltd.