Add OS support for transparent encryption/decryption of stream files in the IFS
On the database side, IBM provided corresponding tooling when it introduced Db2 for i field procedures in IBM i 7.1. Field procedures allow Db2 data to be transparently encrypted/decrypted by ISV solutions. But corresponding tooling for encryption/decryption of stream files is missing.
Most customers maintain business data both in Db2 and in the IFS. OS support for IFS encryption hence covers a major potential security issue.
Existing ISV solutions for transparent encryption/decryption use the IBM i malware scanning exit points to hook into IFS processing. However, the malware scanning exit points were not designed for this purpose, so ISV solutions have to overcome multiple technical obstacles:
- Certain operations on stream files, such as file moves, are not visible to the malware scanning exit points, but have to be taken into account by the encryption solutions. Those operations need to be tracked by using object journaling. Journal entries record information using object IDs; the exit point uses file paths. The journal entries represent a separate, asynchronous source of event-type information, which the ISV solution then must attempt to reconcile with the exit point information and processing. This is especially challenging in high-volume environments.
- Individual file-close events can lead to the Integrated File System Scan on Close exit point being traversed multiple times, causing redundant processing by the ISV solution.
- Due to the nature of the scan exit points, stream files will exist in clear-text for a short time before they are encrypted. This is incompatible with security regimes that require sensitive files to be encrypted throughout their entire lifecycle, such as PCI-DSS.
- Even if only part of a stream file has changed, the ISV solution always has to re-encrypt the entire stream file, causing unnecessary overhead.
To improve security for data in the IFS i, improve PCI-DSS compliance, and reduce processing overhead, we request the addition of OS support for the transparent encryption/decryption of stream files. This support should satisfy the following requirements:
1) It should be possible to determine on a per-stream-file level or at least a per-IFS-directory level whether the ISV encryption solution will be called when the file is accessed.
2) The ISV encryption/decryption solution must be called automatically when a stream file is accessed, comparable to field procedures or exit points.
3) The ISV solution can return either of the following to the OS via a defined interface: a) the encrypted/decrypted data, or b) an error code to indicate the access is denied.
4) The access logic, i.e. which accesses are allowed and result in the file being decrypted and which are not, is implemented by the ISV solution.
5) Transparent implementation / minimal impact on existing applications. Assuming that the access is allowed by the ISV encryption solution, encryption/decryption would be completely transparent to applications.
6) If only a part of a file is changed, only that part has to be re-encrypted by the ISV solution. E.g., when changes are made to the file, only the modified storage pages would need to be re-encrypted.
Use Case: Company Acme Inc. stores and exchanges, via NetServer, sensitive files in IFS directory /M3/exchange. The files contain sensitive data. Acme, Inc., wants to protect those files from accidental or malicious snooping, including from *ALLOBJ user profiles.
Encryption would be used to transparently and automatically encrypt the contents of all files in that directory when written. When a job attempts to read the file, the encryption software will determine if the user is on an access list and if yes, decrypt the file contents on the fly for that request, but leave the file encrypted on the disk. Users that are not on the access list just get an error message.
I have a similar one . I have to upload an GPG encrypted Ifs txt file to a supplier server The Key to encrypt is given by the supplier . For what I see no any support for OpenGpg or similar. Some clear and easy supported command to encrypt the ifs txt file would be very useful , Could be some new Sql Function on or similar...
Therese Eaton, Steve Bradshaw: Thank you for your feedback. While I think everyone would appreciate a "total system data at rest encryption solution", but if it is based on disk/ASP encryption, then the protection from that is limited. Disk encryption works by decrypting disk contents for all IBM i jobs, regardless of the user profile requesting the data. It protects against scenarios where disks are stolen from a data center -- assuming that the USB stick with the key is nto stolen with the data. The same limitations would apply to main storage encryption, the like of which is available on IBM Z today. If main storage gets decrypted for any job, protection is limited.
A more likely scenario is malicious system access (from outsiders or insiders), and disk encryption cannot help there. Having the capability to decide based on the user profile which file is decrypted and which not, is a much better protection in that threat scenario, as it moves the requirement for an attacker from having access to any job to having access specific user profiles, a much higher obstacle.
We will continue to evaluate how we can better enable a solution provided by an ISV.
The CEAC has reviewed this requirement and recommends that IBM view this as a MEDIUM priority requirement that should be addressed.
The CEAC sees that this has broad appeal but given the workarounds that are in place today we would rather IBM put its efforts into a total system data at rest encryption solution.
Background: The COMMON Europe Advisory Council (CEAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CEAC has a crucial role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community and has therefore reviewed your RFE.
To find out how CEAC help to shape the future of IBM i, see CEAC @ ibm.biz/BdYSYj and the article "The Five Hottest IBM i RFEs Of The Quarter" at ibm.biz/BdYSZT
Therese Eaton – CEAC Program Manager, IBM
Hi Kurt
I believe the long term solution of what you are asking for, is to encrypt all ASPs including SysBas, to give the entire LPAR data a rest encryption, you can do this today if you have external storage.
It's not all bad news, you can do this encryption at rest today with internal storage as long as you don't mind creating another ASP for the IFS directories you want to encrypt.
To do this, you would need to create one more new ASP's, install the chargeable (but not expensive) LLP 5770 SS1 Option 45 Encrypted ASP Enablement, then you can mount your encrypted secondary ASP's so that the data is encrypted at rest and as you request transparently encrypted and decrypted as it is accessed.
I hope this helps.
Cheers Brad
Steve Bradshaw
IBM Champion, Member of CEAC, TD of i.UK.co.uk
and by day a Friendly Techie Bloke at RowtonIT.com
IBM has received the requirement and is evaluating it. IBM will provide a response after evaluation is complete.
The CAAC has reviewed this requirement and recommends that IBM view this as a medium priority requirement that should be addressed. This would be one of the better RFEs to implement to provide better infrastructure for an ISV solution.
Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.
For more information about CAAC, see www.common.org/caac
Nancy Uthke-Schmucki - CAAC Program Manager
Note: An earlier request for IFS encryption support, 112270, was closed because there were "ISV Security Products available to encrypt files in IFS." The submitter works for a company that creates one of those solutions. We are not suggesting that IBM create a fully fledged encryption solution, but to add better OS support that could then be used by such a solution.