1. requirements demystified
PCI Encryption
requirements demystified
Andreas Lutz
comForte GmbH
November 2007

2. comForte company Introduction
Our Mission: Assisting enterprises to deploy secure, manageable and cost-effective NonStop server access
comForte GmbH / Germany
Founded: Oct 1998
CEO: Dr. Michael Rossbach CTO: Michael Horst
Offices:
Neuruppin (north of Berlin)
Wiesbaden (near Frankfurt)
comForte Inc. / USA
Founded: June 2005
President: Knut Rossbach CTO: Thomas Burg
Office: Old Tappan, New Jersey
Employees: 25
Customers: 400
comForte is founded The CO is Dr. Michael Rossbach. The headquarter is located in Neuruppin. Our second office is in Wiesbaden near Frankfurt. In the year 2005 we founded the comForte Inc in New Jersey. More than 600 customers worldwide are using our products.
communication is our Forte

3. Agenda Part 1: PCI DSS encryption requirements
Part 2: Encryption Standards and Technologies
Part 3: comForte products helping to achieve PCI compliance
• In Part 1, we will (literally) look at the verbage of the PCI DSS document
• In Part 2, we will match the encryption requirements to current Standards and
Technologies
• In Part 3, we will present the comForte products implementing these Standards
Disclaimer: – While the information in this presentation is believed to be accurate, only your PCI
auditors can decide about compliance and non-compliance

4. Part 1: PCI encryption requirements
What is the PCI standard anyway:
PCI Introduction
PCI DSS stands for Payment Card Industry (PCI) Data Security Standard (DSS). It was developed by the major credit card companies as a guideline to help organizations that process card payments prevent credit card fraud, hacking and various other security issues. A company processing, storing, or transmitting credit card numbers must be PCI DSS compliant or they risk losing the ability to process credit card payments.
The PCI DSS reflects the combined interests of VISA, Mastercard, Discover, American Express, and JCB. These five credit card brands have agreed upon a common set of security standards. Prior to this each card brand managed their own set of requirements:
I‘m sure everybody here knows what PCI standard is, but for some references and to complete the presentation I found one definition at wikipedia.
PCI is a guidline to help organizations that process card payments prevent credit card fraud, hacking and various other security issues. And every company who is processing, storing or transmitting credi card numbers MUST be PCI DSS compliant or they risk losing the ability to process credit card payments.
From the history every credit card brand had their own regulation in security issues. And therefore it was a useful decision to create a common set of security standard.

5. Get the PCI standard at: https://www.pcisecuritystandards.org/
You can download the PCI Standard at pcisecuritystandards.org. It‘s not too long to read. I think thats 20 pages at all.

6. Overview of PCI DSS requirements
Lets have a look at the actual document. And if you look at the table of contents its splitted into 12 individual requirements.
Compared to other security standards like HIPPA which is a MUST to protect medical data the PCI DSS is a much more better written and easier to implement. As mentioned the PCI document may have 20 pages, the HIPPA regulation more than 300. Other security standards like ISO has a similar breakdown like PCI. But as mentioned PCI a well written and easy readable document.
Furthermore if you look to the 12 requirements there are some requirements which basically do not apply for the NonStop world. For example requirement 5: Use and regulary update anti-virus software.
Or requirement 12: Maintain a policy that addresses information security: hat is typically more addressed to the corporate level or an enterprise level rather than on the NonStop platform level.
Other parts of the standard like requirement 7: restrict access to cardholder data by business need to know: this is historically has been done very well on the NonStop using User names, having safeguard and further more.
Other requirements are important for nonStop as well like requirement 2,3,4,6 and 8. And we will now have a look a little bit more in detail to this requirements.

7. PCI requirement 2: Requirement 2:
If you read the sentence that doenst look like its applying for the NonStop platform, because I guess everybody change super.super password from time to time. But under sub-requirement 2.3 it says:
2.3 Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS (transport layer security) for web-based management and other non-console administrative access.
Translating that for the NonStop environment: Telserv is a non-console administrative access or Telnet. That basically means: You have to encrypt Telnet.

8. PCI requirement 3: Protect stored cardholder data
3.1 Keep cardholder data storage to a minimum.
3.2 Do not store sensitive authentication data subsequent to authorization (even if encrypted).
3.3 Mask PAN when displayed (does not apply to employees and other parties with a specific need to see the full PAN)
3.4 Render PAN, at minimum, unreadable anywhere it is stored by using any of the following approaches:
Strong one-way hash functions (hashed indexes)
Truncation
Index tokens and pads (pads must be securely stored)
Strong cryptography with associated key management processes and procedures.
The MINIMUM account information that must be rendered unreadable is the PAN.
If for some reason, a company is unable to encrypt cardholder data, refer to Appendix B: “Compensating Controls for Encryption of Stored Data.”
3.5 Protect encryption keys used for encryption of cardholder data
3.6 Fully document and implement all key management processes
The next requirement 3.4: Render Card holder number at minimum, unreadable by using the following approaches. There are 4 approaches. The first three really mean you not storing the the cardnumber as on the database. The first means to use it on a one way, but if you need to do a search on the cardholder number the first 3 really do not apply. That leaves the last option: Strong cryptography with associated key management processes and procedures. That calls for Database encryption but that is from the whole standard the hardest part to realize. Well I’m not the technical expert, but there are very less tools on NonStop market to solve such requirements.

9. PCI Standard and the NonStop platform
Requirement 3: calls for DB encryption
Nearly all NonStop customers use „Appendix B: Compensating Controls“
This is *hard* to implement – the devil is in the details
And therefore there is an Appendix on the PCI DSS: Compensating Controls for requirement 3.4. Don’t would read the total, but it means:
If you can’t do database encryption, and
if you approved you cant do it, and
if you have the whole analysis why you can’t do it –
you don’t have to encrypt the data on the database, but then you have some other additional measures.
Right now customers tried to refer to the Appendix B
It’s a difficult topic. If you have any questions I think the best is to bring you in contact with our security experts to discuss this topic more in detail.

10. 4.2 Never send unencrypted PANs by e-mail.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
4.1 Use strong cryptography and security protocols such as secure sockets layer (SSL) / transport layer security (TLS) and Internet protocol security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks.
Examples of open, public networks that are in scope of the PCI DSS are the Internet, WiFi (IEEE x), global system for mobile communications (GSM), and general packet radio service (GPRS).
4.2 Never send unencrypted PANs by .
Moving on in the standard requirement 4.1 talks of the requirement to encrypt data during transmission over a open, public networks. And that may or may not apply to an organzation because not all open networks are public, but it’s not too relevant, because if you look at reqiurement 8.4:

11. PCI Requirement 8: Assign a unique ID to each person with computer access (excerpt)
the requirement comes again from a different angle and than it says: encrypt all passwords during transmission and storage on all system components. And that’s no longer distinguishing between private and public networks. So here is another requreiment to encrypt Telserv, because passwords are going across the wire but that also applies FTP and potentially all other protocols you use.

12. PCI DSS and NonStop –summary
Different areas of the standards apply different to the NonStop platfom
Some have been taken care of well over the past 20+ years on NonStop
Some do not apply
Others are typically adressed at an enterprise level
Some other typically require changes
Regarding Encryption and in a nutshell, the PCI standard requires
Encryption of sensitive data (cardholder data, passwords) in transit:
Encryption of Telnet and FTP traffic
Encryption of cardholder data at rest
Databases
Backup tapes
That was a short abstract from the PCI regulation. Many areas of the requirements (i.e. Physical security) are taken care of well in the NonStop environment while others (Anti-Virus) do not apply on NonStop
Some other areas require changes for many customers.
With the focus of encryption today in a nutshell the PCI standard acts for three tings:
The encryption of telnet and FTP
Encryption of data at rest – specifically on backup tapes and the encryption of cardholder data in your database.

13. Part 2: Encryption Standards and Technologies
After we talked about which requirements have to be solved, we will now have a look on how can solve the PCI requirements. And we will see that for some areas there are several Encryption standards where we have to choose from.

14. PCI Encryytion Requirements 1/3: Encrypt Telnet, FTP and other network protocols
So one requirement we examined in the first part is to encrypt Telnet, FTP and other network protocols and I have a table here which talks about from where the standard comes from. It comes from multi places The technology is basically SSL and SSH. And the next slide shows the differences.

15. Telnet and File transfer –Picking the right protocol and products
Two protocols to choose from:
SSL
Evolved through the Internet (“https”)
Popular on PC file transfer clients since 2001
Available from comForte since 1999
Natural fit for file transfer with IBM mainframes and 6530 Telnet
SSH
Comes out of the Unix world
Popular on PC file transfer clients since 2005
Available from comForte since 2003 (file transfer)/2007(6530 shell)
Natural fit for communication with Unix
Natural fit for OSS shell traffic (i.e. with PuTTY)
Choosen by HP for NonStop Console Telnet/FTP encryption
You may need to implement both …
SSL evolves trough the internet. So when you browsing to a secure website you are using https, rather than http. It has become popular for file transfer on the PC early We had our first product since It is a natural fit for file transfer with IBM mainframe because ist part of the IBM mainframe FTP server. Ist also a natural fit for Telnet and other middleware protocols like MQ-Series or ODBC or any other single socket protocol.
So thats for SSL.
SSH is another secured protocol. It comes out of the UNIX world. It became popular on PC‘s a little bit later – in Our first solution was 2003.
It is a natural fit for communication with UNIX systems, because there is running the openSSH.
Itr‘s also natural fir for OSS shell traffic – if you have a UNIX guy, typically what he would expect as a client to connect UNIX system is use PuTTY Emulation where is SSH build in, rather than SSL.
It‘s also the protocol which HP choose for the NonStop console encryption. I guess you have heard that the new emulation on the NonStop console is our Emulator MR-WIN6530 and the RFP from HP specifically stated that the Emulation on the counter part on the NonStop should support the SSH protocol.
Which security protocol you should use depents on the corporate security policy. It may that your company has decided the global standard is SSH , because the had bought SSH solutions for all platforms – or the standard may SSL.
We have a couple of customers who are using both protocols.

16. PCI Requirements 2/3: Encrypt databases
Moving to the next requirement: Encrypt databases. I mentioned that already 3.4 render creditcard number unreadable by encrypting if the other coises do not apply and then get more in the details: fully document and implement all key managament processes and procedures. So have to tape the keys, you have to store the keys you have to retire the keys – thats pretty complex.
Technology is envolved: One technology is your application and the way you write stuff to the database. That is relevant becaus it could use one of the three databases. You could use ENSCRIBE, SQL/MP and SQL/MX. Also programing language will affect the choises.
However, There is no off-the shelf solution for the NonStop platform for transparent encryption available.

17. DB encryption: The challenges (1)
three databases (ENSCRIBE, SQL/MP, SQL/MX)
(as of now:) no hooks for third-party vendors in SQL/MP or SQL/MX
lack of features in SQL/MX which allow “transparent”encryption (triggers,
views, triggers on views, user functions in C)
As alreeady talked about the chanllenges already:
3 databases, there are no hooks in SQL/MP or MX where vendors like ourself or any other could add functionality also if you look how it is done on other platforms the use some enhanced database features which allows transparent encryption like triggers, views, triggers on views, user function in C. And if you have those you can make changes transparently to the application more easily.
And that is not avaliable on the NonStop.

18. DB encryption: The challenges (2)
Key management,
key rotation, ...
searches for
encrypted data ?
“find next”for
I mentioned already key management, key rotation, that is in fact the part of requirement 3.6 :
You have to generate strong keys, distribute them securely, store them securely, change them, destruct old keys, split knowlege – so thats really a big of work and if you would like to create this from the scratch this is really very complex.

19. PCI Requirements 3/3: Encrypt backup tapes
The third requirement: Encryption of backup tapes.
Basically there are two technologies avaliable: a hardware based and a software based encryption. Before we talk about benefits of both solutions I would like to show you a slide regarding Backup Tape misusage:

20. “No-one can read Tandem tapes ?”
Maybe you have heard about DEF CON. DEF CON ist like a hacking convention – but not really the criminal one. One of the topics was how many tapes gone „missing“ and what could do with them. When it happens they say typically to the customers, that these tapes can not be read without specific computer equipment and software, in attempted damage control – and than it says: We will look at how easy it is to recover data from tape.
And the result is that there are reader available for 500 or 1000 USD to recover data from tapes, and there is software avaliable to read data without the header.

21. Backup tape encryption: Technologies
Keeping that in mind, one of the technology options for backup tape encryption is the hardware base solution which is typically an extra box which gets daisy changed into the cable between the NonStop box and the backup tapes.
The benefit is that it is transparent to the existing environment.
There is no performance impact on the hardware and that the encryption keys are safely stored in the hardware.
But one point on the downside is the high costs to have many hardware boxes for the several server systems. That could be really expensive.
The other backup tape technology is the software based solution.
This variant is very easy to test, it‘s just to download the software and maintain it. There is no installation of new hardware. But normally there is an impact on the CPU usage. Encrypting data in software has an impact.

22. Part 3: comForte products helping to achieve PCI compliance

23. comForte and encryption on NonStop
MR-TN6530
MR-WIN6530
SSL for terminal emulation
SecurTN
SecurFTP/SSL + SecurCS
SecurCS for Websphere MQ
WIN6530, J6530 with integrated SecurFTP client
HP licenses comForte’s SSL technology for internal use
SecurFTP/SSH, SecurPrint
SecurSH, SecurTape
HP licenses comForte’s SSH technology for internal use
MR-Win6530 on NonStop Console
SecurSH in HP price book

24. comForte security solutions in production
SSL Telnet Server (FCS 2000)
more than 100 customers
more than 300 NonStop systems
SecurFTP/SSL (FCS 2002)
more than 20 customers
more than 50 systems
SecurCS for Middleware (FCS 2002)
SecurSH (FCS 2004)
more than 15 customers
more than 80 systems

25. The Telnet and file transfer scenario before encryption
Lets start withtelnet and file transfer solutions. That slide here shows the typical NonStop system without any products to encrypt the Telnet or FTP.
So you have Telserv, You have telserv connecting on the NonStop with TACL and Pathway and OSS. You have the FTP server, the NonStop product and the FTP client.
On the other end could be a PC or a UNIX server or a IBM for file transfer.
You have a 6530 emulation client , an OSS emulation client, FTP clients and servers and all communication is not encrypted, witch is depicted by the red arrows.

26. comForte products for Telnet/FTP encryption using SSL
Now we see the same slide but with our SSL encrypted products in place. You may remember that we talked before that SSL and SSh are just two protocols apply nicely and are standard based and we offer both.
Both products, SecurCS and SecurFTP/SSL work as a proxy. So it‘s another process on the NonStop system and the frond-end Terlserv and the FTP components.
But from Telserv and FTP NonStop components there is really no difference. So there is here a connection which is not encrypted, but the connection over the network is encrypted with SSL.
And on the other end you need some components which are SSL enabled, like an SSL enabled FTP client, or an SSL enabled FTP server, an SSL enabled emulation client. And then the communication will be encrypted.

27. comForte products for Telnet encryption using SSL (contd)
We also have a product it‘s called SecurTN, which fully replaces Telserv. For Telnet only.
We have created this product because some customers wanted a more integrated solution and as we dont have the TELSERV sources thats the only way to do to fullly replace it.
It‘s also does a way with some of the limitations of the Telserv product so can run thousands of sessions over a single process whereas with Telserv you can only run 255 sessions.

28. comForte products for Telnet/FTP encryption using SSH
Now for SSH for file transfer and Telserv our product is called SecurSH for the whole thing or the product SecurFTP/SSH for file transfer only.
They fully replaces Telserv as well and they also do use no longer the normal FTP components on the NonStop. So you see that they interact directly with the file system.
On the remote end you now an SFTP, that is the name of the file transfer protocol, enabled client or daemon, a sort of UNIX language here for the server. And you need an SSH enabled emulation for that.

29. Encryption of Telnet and File transfer: summary

30. SecurTape
Next product to comply to the PCI standard is the encryption of Backup tapes. This slide shows a little bit the architecture. I think it‘s alittle bit to much detailed but in a nutshell we bind a library in the backup object file.
It is a s software solution we have done quit a bit of tweaking by now to make it as fastest as possibe and to use as little CPU‘s as possible. To achieve this it use a rather fast compression algorythm so first thing the data is compressed and than it‘s encrypted. And compression is in fact faster than encryption. So the better the data and also uses less CPU.
Also we have added capability lately where you can spread the CPU load across multiple CPU‘s. So rather than using a lot of CPU‘s in a single CPU you be using like a little bit of CPU‘s in multiple CPU‘s.
The key store: The keys are in software in a flat file but they are protected by key store rather than being key by key seeing a file.
SecurTape is pretty easy to install so it‘s also easy to test

31. SecurTape - CPU usage/throughput
“It depends”
More impact for slower CPU, faster tape drive
The more CPU cycles it uses, the faster SecurTape will be (!)
We have seen elapsed time for BACKUP jobs being about same, smaller or a bit larger
Test it in your environment …
The question we get ask all the time when we talk about SecurTape is: How much slower is it, is it slower, how many CPU cycles will I use and we would like to give you a singel, simple answer like plus 5% or +10% but it depends on a lot a lot of factors.
One factor is how fast yourTapedrive is. If it‘s a slow Tapedrive you probably you want see a lot of impacts because the tapedrive is the limitation factor anyway.
Another factor is the CPU‘s you are using.
A third factor is how well the data compresses

32. Database encryption with SecurDB
comForte’s vision:
Don’t reinvent the wheel on NonStop
Bring cross-platfrom solutions to NonStop
comForte partnering with Ingrian, Industry leader in DB encryption
Leverage a centralized, standard-based approach to increase ROI and cross-platform
capabilities
Hardware encryption for compliance with legislation and policy
(optional) FIPS Level 3 compliant
Encryption in SW alone

33. Database encryption with SecurDB

34. Summary

35. Thank you for your attention
For further information please contact:
Andreas Lutz
Sales Representative
Phone: +49 (0)
Fax: +49 (0)