It has been three decades since the first website was created. And with a rose, comes thorns. Although the internet has revolutionized the way we live our lives, it has also opened new avenues for crime. In 2022, the ransomware payment rose 71% from the previous year, approaching the unprecedented US$1 million mark during the first five months of 2022.
If you have yet to pay any ransom, the credit likely goes to your security information and event management (SIEM) or extended detection and response (XDR) provider. Most organizations outsource their information security operations center (SOC) to a cloud vendor. System and audit logs are collected from stationary or mobile and thick or thin clients, and fed to these SOCs to generate alerts for a possible incident of compromise (IoC). These logs are in textual form, and unencrypted (plaintext) access is required to process them. But not all vendors are created equal. The logs may contain sensitive information about the organization or the customers of the organization, and a vendor may have enough incentive to monetize this data. Thus, it becomes a challenge to preserve privacy while outsourcing.
Before deployment, consider the following:
- How to preserve the security and privacy of data at rest
- How to safeguard the security and privacy of data in transit
- How to maintain the security and privacy of data during use
There are two ways to address this: silicon or software. While using a trusted execution environment (TEE) achieves the hardware approach for privacy-preserving operations, the software-based solution is realized by deploying fully homomorphic encryption (FHE).
A TEE is an isolated private enclave that provides integrity and confidentiality for both data and code. In addition, a TEE prevents unauthorized access from other applications, admins, operating systems and hypervisors. However, although the TEE seems like it is the ultimate solution, it has a few weaknesses. For instance, TEEs are not supported for older machines requiring hardware upgrades. Furthermore, they have limitations on the amount of data that can be secured (e.g., Intel SGX has a limited protected memory of 128 MB). In addition, they are vulnerable to side-channel attacks.
Therefore, I bet my money on FHE. Popular FHE schemes include Brakerski-Gentry-Vaikuntanathan (BGV), Fan-Vercauteren (FV) or Brakerski-Fan-Vercauteren (BFV), and Cheon-Kim-Kim-Song (CKKS). These schemes have roots in the mathematical concepts of the hardness of the ring learning with errors (RLWE) problem, where noise is added during encryption and key generation to achieve hardness (i.e., security) properties.
FV/BFV and BGV schemes are similar, and the computations are performed on integers. And CKKS allows calculations on complex numbers with limited precision. FHE enables you to perform and preserve computations on encrypted data as if they were done on unencrypted data. FHE can be applied to log anomaly detection problems so organizations can parse and encrypt their logs before sending them to the SOC for processing and get an encrypted result back, decrypting which results in the knowledge of an IoC or alert to the security admins. But, unfortunately, FHE, at an early stage, suffers from high computation and communication costs. It also only supports limited operations such as addition, subtraction and multiplication.
Editor’s note: For further insights on this topic, read Devharsh Trivedi’s recent Journal article, "The Future of Cryptography: Performing Computations on Encrypted Data," ISACA Journal, volume 1, 2023.
