Hi Team, I wondered if anybody had any thoughts on the above. I dont want the names of products to help do this, this question specifically regards whether the 3270 data stream, in the instance from CICS should be encrypted. So, for SNA 3270 the data path is somewhat of a Private network, where pseudo encryption exists because the X.25 data frames are proprietary and notoriously hard if not impossible to decipher. However, when using an IP data path, by definition there is a Private to Public data path evolution, and of course TN3270 does not encrypt the data path by default. OK so the IP Network will have a Firewall and therefore a good level of Security, but were homing in on the CICS data path
Thus, hypothetically speaking, for a business critical call centre type workload, required ~24*7*365, with data that is sensitive, including Name, Address, Financial and Government details, would you encrypt the TN3270 data path or not; so please answer: 1 Yes 2 No Thank you; I will then publish the results after a week or so. It would seem to me that SOX, HIPPA, FSA, UK Data Protection Act, et al might have some influence here! So, why am I asking this question? Im working with a client on something totally different, but I heard they were performing this conversion. I asked them on their thoughts regarding data stream encryption, and by them I mean the highest levels of management, including the Security & Risk Manager; their reply was, hmmm, didnt realise that, but hey, we dont care, weve got Firewall protection. So if it were your business would you consider encrypting business critical and sensitive data, which could be done with a very simple implementation, for example: TN3270 protocols can easily use SSL (Secure Sockets Layer) functionality, which means that all data is encrypted before it is sent to the client. Encrypted data received from the client is the decrypted before the data is sent to VTAM, but the flows between Telnet and VTAM are unchanged. To use SSL, TN3270 protocols must have a private key and access to an associated server certificate. The TN3270 server can obtain the server certificate and the keys from three different places: * A KDB file stored in an MVS data set * A KDB file stored in an HFS file * The RACF database SSL client authentication provides additional authentication and access control by checking client certificates at the server. This support prevents a client from obtaining a connection without an installation- approved certificate. There are three ascending levels of client authentication that can be defined for TN3270 protocols: Level 1 is the simplest level. To pass authentication, the Certificate Authority (CA) that signed the client certificate must be considered trusted by the server (that is, a certificate for the CA that issued the client certificate is listed as trusted in the server's keyring). If the client is using a self-signed certificate, then the client certificate needs to be in the servers keyring as a trusted CA certificate. You implement this level of authentication by coding CLIENTAUTH SSLCERT in the TCP/IP profile. Level 2 authentication includes level 1 authentication. In addition, level 2 checking verifies that the client certificate has been registered with RACF (or other SAF-compliant security product that supports certificate registration). To implement level 2, the client certificate has to be added to the RACF database and associated with a RACF user ID. The TCP/IP configuration file must have a CLIENTAUTH SAFCERT statement. Level 3 authentication level provides, in addition to level 1 and level 2 support, the capability to map access to TN3270 ports with a SERVAUTH class profile in RACF. Many thanks in anticipation, Michael. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
