In recent years there has been an emergence of several new technologies to protect sensitive data, including Format Preserving Encryption (FPE) and Secure Stateless Tokenization (SST), such as those provided by HPE Security’s SecureData product. These products provide excellent capabilities to assist HPE NonStop users in protecting data within their application environments. Both HPE FPE and HPE SST provide strong protection against the exposure of sensitive data but they should not be used alone or to replace traditional access controls. Data protection methods such as FPE and SST need to be carefully considered and planned alongside traditional access controls to ensure all application data is comprehensively protected both from authorized and unauthorized exposure. This article will give a high-level overview of how to implement a best-of-breed HPE NonStop security framework; protecting all sensitive application files and tables using comprehensive access controls, and also selectively protecting the highly sensitive and valuable data those files may contain, such as credit card (PAN) data or personally identifiable information (PII).
Mission critical applications such as those typically found on the HPE NonStop Server are composed of programs and files or tables. There are multiple levels of access requirements for both programs and files. For instance, only certain programs running as certain users should be able to access tables containing application data. This simple access control rule can be challenging to implement on the HPE NonStop Server, as standard HPE Nonstop security controls do not include the granularity features necessary to implement the desired security. For example, using the requesting object file as an attribute that can be used to control file access is not an option. Standard HPE Nonstop security can only control file access by the user running the program. In addition to the emergence of data protection technologies like FPE and SST, XYGATE Object Security (XOS), which uses the Safeguard Authorization Security Event Exit Process (SEEP), can be used to achieve the desired access controls for application security. This solution can use the requesting object file, among others, as an attribute when making access decisions, thus introducing more granularity into the access control matrix. Other partner products, including those from Greenhouse Software, also support the Safeguard Authorization SEEP.
Encryption and Tokenization Options
In addition to controlling the access rights of users and programs to application data, it is often also necessary to encrypt or tokenize sensitive data in tables to prevent its exposure to non-authorized parties. This may be due to regulations, such as PCI-DSS, industry/corporate regulations, or just a result of the sensitive nature of the data itself. This can create a complex multi-tiered environment, which no single security product can fully address.
Two data protection methods have recently received a lot of focus in the NonStop space: disk (or volume) level encryption and application level encryption/tokenization. As a side note, file encryption is not considered for the purposes of this article as encrypting entire, live application files is generally either impractical, or involves extensive application redesign. Disk level encryption, known as VLE on HPE NonStop, is generally transparent to any logged-on users and therefore only protects against the disk drive being taken off-site and accessed. Due to this constraint, disk level encryption is no longer considered sufficient protection for PAN data, according to the PCI-DSS. Application level encryption also protects against disk drive removal but in addition also protect the data from being accessed by anything other than authorized users or programs.
There are typically two variations of application level encryption:
- Integrated application level encryption
- Transparent application level encryption
Integrated application level encryption/tokenization is implemented by modifying the application programs to encrypt/tokenize and decrypt/detokenize sensitive columns. This can be a very expensive proposition depending on how many programs need modifying. It may also require the application programmers to have encryption programming knowledge, for instance how to manage keys. Also, this method typically precludes the ability, if required, for operating system utility programs to be able to see unencrypted data, since those programs cannot be easily modified. Using integrated application level encryption can make it difficult to share encrypted data with off box applications because those off-box applications would also have to be modified in the same way. HPE offers the HPE SecureData product for customers which want to use the integrated approach – and companies such as XYPRO, comForte and HPE are able to provide consulting services to assist with implementation if that approach is taken.
Transparent application level encryption/tokenization involves attaching a library to each program that needs to access the protected data. The library intercepts all I/O calls, and, based on its configuration, encrypts and decrypts specified fields or columns for specified programs running as specified users. The library can also be attached to operating system utility programs if required, and then those utilities can see unencrypted data. If this library uses underlying encryption technologies that are available on multiple platforms, sharing data with off-box applications is relatively easy. HPE offers two transparent application level encryption/tokenization products; XYGATE Data Protection (XDP) and cF Data Security. Both products provide these features and address these needs, using industry-leading HPE SecureData as the underlying ‘layer’ for encryption and tokenization.
Adding Access Controls into the Mix
When using transparent application level encryption, granular access controls are also important. The encrypting of data has to be combined with the ability to configure which processes, running as which users, running which object files, can access the sensitive data in an unencrypted format. For example, the process running the object file that is used to verify PANs should be granted the authority to see the unencrypted PANs. A process running any other object file should not see unencrypted PANs. An encryption scheme that encrypts and decrypts PAN data for processes running any object file accessing the data provides no better protection than disk level encryption.
Let’s look at some examples of how access control to a tokenization system can be implemented in the XDP encryption library.
FIELD FPE FIELD_POSITION 6:16
The above configuration entry says for any file called CRDTBL on the system, there is a 16 digit PAN starting at position 6 in the record that needs to be encrypted with Format Preserving Encryption. This entry only applies to object files named CRDFPROG run by user APPL.USER. All access is audited and can be captured and/or forwarded to a SIEM using XYGATE Merged Audit.
While the above entry controls how the PAN column is encrypted, and which program can see the unencrypted data, it does not control overall access to the file. Access should be controlled to the file so that only those programs that need to access the file are able to. This is important because the file may contain other information that needs to be protected, not just the encrypted/tokenized PAN. This could be implemented with an XOS entry like the following:
ACL APP1.USER *
REQUESTOR $*.*.CRDPROG $*.*.ALTPROG
The above entry says that for the file $*.*.CRDTBL, which is owned by user APP1.USER, the APP1.USER can perform any file system operations on the file when running a $*.*.CRDPROG or $*.*.ALTPROG program. Note that in combination with the XDP entry above, while ALTPROG can access the file, it will only see encrypted PAN data.
Two applications, one file?
Being able to control the security of a file based on the requesting object also helps in the situation where two different applications need to share a file when the applications run as different users. Assume that there is a primary application and a secondary application that both need access to one file owned by the primary application. Typically the security to access the shared file would need to be granted to both applications UserIDs. However, this means that any program running as one of the secondary applications UserIDs would be able to access the data. Having a security scheme that includes the object file as one of the access controls means that the one program in the secondary application that needs to access the primary applications file will be the only program that can access it. Any other program running as the secondary application’s UserID will not be able to access the data.
The above scheme could be implemented with an XOS configuration entry like the following:
ACL APP1.USER *
REQUESTPR $APP1.OBJ.WRTETXFR $APP2.OBJ.PROCTXFR
The above entry says that for the file $DATAA.APP1.TXFR, which is owned by user APP1.USER, the APP1.USER can perform any file system operations on the file when running the $APP1.OBJ.WRTETXFR program, and that the APP2.USER, when running the $APP2.OBJ.PROCTXFR program, can Read or Write the TXFR file.
HPE NonStop servers and most modern computing platforms have always benefited from a layered approach to security – there is no point locking your windows when your front door is wide open. Newer technologies like HPE Format Preserving Encryption and HPE Secure Stateless Tokenization provide another layer in the security administrator’s arsenal and can be very powerful when deployed in conjunction with more traditional security mechanisms. Just make sure to plan out your complete implementation so that all users and applications get just the access they need, and nothing more. As an added benefit, you’ll also address both PCI-DSS Requirement 7 “Restrict access to cardholder data by business need to know” and Requirement 3 “Protect Cardholder Data”.