Source-linked AI summary
SecLaaS: Secure Logging-as-a-Service for Cloud Forensics
Shams Zawoad, Amit Kumar Dutta, Ragib Hasan
TL;DR
Cloud forensics lacks practical ways to provide investigators with cloud logs while preserving user privacy and log integrity. SecLaaS stores virtual-machine logs, provides controlled forensic access, and preserves proofs of past logs; its OpenStack implementation was found practically feasible. The approach trades Bloom-filter efficiency against a nonzero false-positive probability, while One-Way accumulators provide zero false positives with greater storage requirements.
Problem
Cloud investigators face difficult log collection in multi-tenant infrastructure, and prior proposals did not securely expose logs while preserving user privacy and integrity.
Method
SecLaaS stores cloud users’ logs and uses Proof of Past Log and Log Chain mechanisms to support confidential access and integrity verification.
Results
The OpenStack implementation was found practically feasible, and Bloom filters outperformed One-Way accumulators for log insertion, PPL generation, and log verification.
Takeaways & Limitations
SecLaaS provides a cloud logging service in which auditors can check log integrity while cloud-user confidentiality is preserved.
Takeaways & Limitations
Bloom filters have a nonzero false-positive probability, whereas One-Way accumulators provide zero false positives at higher storage cost.
Abstract
from arXiv · showhide
Cloud computing has emerged as a popular computing paradigm in recent years. However, today's cloud computing architectures often lack support for computer forensic investigations. Analyzing various logs (e.g., process logs, network logs) plays a vital role in computer forensics. Unfortunately, collecting logs from a cloud is very hard given the black-box nature of clouds and the multi-tenant cloud models, where many users share the same processing and network resources. Researchers have proposed using log API or cloud management console to mitigate the challenges of collecting logs from cloud infrastructure. However, there has been no concrete work, which shows how to provide cloud logs to investigator while preserving users' privacy and integrity of the logs. In this paper, we introduce Secure-Logging-as-a-Service (SecLaaS), which stores virtual machines' logs and provides access to forensic investigators ensuring the confidentiality of the cloud users. Additionally, SeclaaS preserves proofs of past log and thus protects the integrity of the logs from dishonest investigators or cloud providers. Finally, we evaluate the feasibility of the scheme by implementing SecLaaS for network access logs in OpenStack - a popular open source cloud platform.
1. INTRODUCTION
Cloud forensics is hindered by difficult log acquisition and the lack of secure ways to preserve user confidentiality and log integrity. The paper proposes SecLaaS, including Proof of Past Log, and evaluates it on an open-source cloud platform.
- Motivation: Cloud investigators depend on providers for logs because cloud infrastructure offers limited investigator control and may leave no useful traces after virtual machines are terminated.A colluding provider may also supply tampered logs that investigators cannot independently verify.
- Research gap: Existing log APIs and management-console proposals did not show a practical secure method for exposing logs while preserving user privacy and preventing tampering.The paper identifies confidentiality and integrity as requirements for trustworthy log-based forensics.
- Proposed approach: SecLaaS exposes cloud users’ logs for forensic investigation while preserving their confidentiality from malicious employees or external entities.The scheme is introduced as a secure logging service for cloud environments.
- Proposed approach: Proof of Past Log is a tamper-evident scheme intended to prevent cloud providers or investigators from manipulating logs after the fact.It supports preserving evidence integrity after logs have been published.
- Evaluation: The authors evaluate the proposed scheme using an open-source cloud computing platform.The paper later identifies OpenStack as the implementation platform.
2. BACKGROUND AND CHALLENGES
Cloud forensics applies forensic procedures to cloud environments, where acquiring and presenting logs is difficult because control is limited, evidence is distributed and co-mingled, and integrity must be demonstrated. These challenges vary across cloud service models and stakeholders.
- Definitions: Cloud forensics applies computer-forensics procedures in cloud environments and includes technical, organizational, and legal dimensions.Its procedures vary according to the cloud service and deployment model.
- Log-forensics challenges: Process, network, and application logs are valuable forensic evidence, but cloud characteristics can make gathering them difficult or sometimes impossible.Investigators therefore face a more difficult log-analysis task than in privately owned systems.
- Reduced control and CSP dependence: Customers have the most control in IaaS and the least in SaaS, while access to network, database, and operating-system logs often depends on the CSP.In SaaS, customers receive no system logs unless the provider supplies them; in PaaS, customers can generally obtain application logs.
- Decentralization: Cloud logs are decentralized across servers and architectural tiers, including application, network, operating-system, and database layers.Multiple users’ logs may be co-located or distributed across the infrastructure.
- Accessibility: Access control must provide each stakeholder only the logs needed for administration, development, or forensic investigation.The required access differs across system administrators, developers, and investigators.
- Multi-tenancy and evidence integrity: Multi-tenancy can mingle different users’ data in shared infrastructure, while cloud jurisdiction and presentation requirements complicate chain of custody and courtroom proof.Investigators must establish how evidence was collected, preserved, and shown to be intact.
3. THREAT MODEL
The threat model treats users and investigators as potentially malicious and allows a CSP to collude with them after publishing proofs. SecLaaS addresses privacy, log ownership, ordering, modification, and repudiation threats.
- Adversary assumptions: The model assumes users and investigators do not trust CSPs, while CSPs are honest when publishing the Proof of Past Log and Log Chain.During investigation, the CSP may collude with users or investigators and provide tampered logs.
- Attack surface: Threats include privacy violations, log removal, false-log planting, reordering, repudiation by CSPs, and users’ denial of log ownership.Investigators may also tamper with logs before presenting them to court.
- Security goals: SecLaaS aims to preserve cloud users’ logs in persistent storage and prevent malicious parties from producing false proofs of past logs.Published proofs should not be modifiable or repudiated by the CSP.
- Security goals: The system is intended to prevent CSPs from removing, reordering, or planting logs after publication.These integrity properties cover both log contents and their original generation order.
- Security goals: The system is intended to prevent investigators from hiding, reordering, or presenting phony logs when submitting evidence to court.These properties address contamination during forensic presentation.
- Confidentiality goals: Confidentiality goals prevent adversaries from recovering logs from published proofs or malicious employees from recovering logs in storage.The threat model includes employees of the CSP among potential intruders.
4. THE SecLaaS SCHEME
SecLaaS retrieves cloud logs, protects sensitive fields, chains entries to preserve order, and publishes proofs of past logs for later verification. Investigators verify both proof and entry integrity, then confirm log sequence.
- Overview: SecLaaS extracts logs from node controllers, stores them persistently, and makes them available to forensic investigators.The system targets logs generated by the node controller for each running virtual machine.
- Log and proof construction: Encrypted Log Entries protect confidential fields with investigators’ shared public keys while leaving searchable fields available to the CSP.For network logs, destination IP, port, and user information can be encrypted.
- Log and proof construction: The Log Chain hashes each encrypted entry with the previous chain value to preserve the correct order of log entries.Each persistent database entry contains the Encrypted Log Entry and its Log Chain.
- Log and proof construction: The logger creates accumulator entries for database logs and generates a daily Proof of Past Log from the day’s final accumulator entry.The proof is published with the CSP public key and can also be shared through RSS or other CSPs.
- Verification: Auditors validate the published proof and each log entry, then verify sequence by recomputing the next Log Chain from consecutive entries.A log is accepted in the order check when the recomputed chain matches the second entry’s stored chain.
5. SECURITY ANALYSIS
SecLaaS is designed to detect log removal, insertion, reordering, repudiation, and disclosure under collusion among cloud providers, users, and investigators. Its security analysis uses accumulators, encryption, hash chaining, and signatures to protect log integrity and confidentiality.
- Threat Model: The threat model considers eight collusion combinations among cloud service providers, users, and investigators, with corresponding attacks and required security properties.The model allows each entity to be honest or dishonest and permits individual or colluding behavior.
- Integrity Protection: Hash-chain sequence verification detects removed or reordered log entries because altered sequences no longer match the published chain state.The analysis illustrates detection when an entry is removed or entries are presented in the wrong generation order.
- Integrity Protection: Accumulator membership checks detect phony logs because a fake log's accumulator entry is absent from the published Proof of Past Log.This protects against false information planted by a colluding provider or fabricated by an investigator.
- Integrity Protection: A cloud provider cannot repudiate a published proof because its accumulator entry is signed with the provider's private key.Verification compares the decrypted signed value with the hashed accumulator entry.
- Confidentiality: Bloom filters and one-way accumulators protect stored proofs from revealing logs, while encrypting identifiers and destination IPs protects confidential log fields.The scheme uses a common public key for investigator agencies to prevent malicious cloud employees from recovering plaintext information.
6. IMPLEMENTATION AND EVALUATION
The authors implement SecLaaS for network logs in an OpenStack testbed and evaluate Bloom-filter and one-way-accumulator configurations. Log insertion and verification scale differently across accumulators, while logger overhead is measured at 1.6%.
- Implementation: SecLaaS is implemented with OpenStack, Snort, VirtualBox, and a single Ubuntu host using two virtual machines for network-log collection.The setup uses RSA-2048 signatures and SHA-256 hashing; Snort tracks virtual-machine network activity.
- Implementation: Public IPs are mapped to user information through references among OpenStack's FloatingIps, FixedIps, and Instances tables.This database-based resolution links a network log's public address to the corresponding cloud user.
- Evaluation Setup: The evaluation compares Bloom filters at 1% and 2% false-positive probabilities with one-way accumulators using 32-bit and 64-bit parameters.The configurations vary Bloom-filter capacity and the sizes of P, Q, and X for one-way accumulation.
- Performance Results: Log-insertion time increases linearly with log size for all accumulators, while changing the one-way accumulator from 32-bit to 64-bit produces a significant time increase.The two Bloom-filter configurations have nearly similar insertion times.
- Performance Results: Proof-of-Past-Log generation is nearly constant for Bloom filters but increases linearly with log size for one-way accumulators.The one-way case requires computing an identity for each log entry.
- Performance Results: Verification time remains nearly constant as log size increases, but 32-bit and especially 64-bit one-way accumulators take longer than Bloom filters.The 64-bit accumulator has significantly higher verification time than the other evaluated configurations.
7. DISCUSSION
The Bloom filter outperforms the One-Way accumulator across log insertion, proof generation, and verification, but trades zero false positives for probabilistic membership checks and storage overhead.
- The Bloom filter outperforms the One-Way accumulator for log insertion, PPL generation, and log verification.
- Bloom filters have zero false negatives but retain a nonzero probability of false positives when verifying log existence.
- For 10,000 elements, achieving 0.1% false-positive probability requires 111945 bits, or 13.67 KBytes, per filter.
- One-Way accumulators provide zero false-positive probability but require substantially more storage for precomputed log identities and slower performance than Bloom filters.For 10,000 records, storage requirements are 97.67 KBytes for 32-bit and 195.35 KBytes for 64-bit accumulators.
8. RELATED WORKS
Prior work addressed cloud logging collection, monitoring, and secure logging, but did not provide a practical cloud logging service that handles privacy, integrity, and collusion concerns.
- Marty proposed synchronized, reliable, bandwidth-efficient, and encrypted transport for logs collected from infrastructure components.
- Zafarullah et al. used Eucalyptus monitoring tools to collect logs and identify attacking machines, browser types, requested content, and VM communication patterns.
- Bark et al. proposed read-only APIs for exposing network, process, and access logs, while Dykstra et al. recommended a cloud management plane.
- Existing secure-logging work addressed privacy and integrity against external entities but did not consider dishonest loggers or collusion among entities.
- Unlike the closest prior scheme, SecLaaS reports almost constant log-verification time as the number of logs increases.
9. CONCLUSION AND FUTURE WORK
SecLaaS securely stores and provides cloud logs for forensic investigation while preserving user confidentiality and enabling integrity checks through proofs and log chains.
- SecLaaS addresses the lack of a way to provide investigators with cloud logs while preserving both user privacy and log integrity.
- The scheme lets cloud service providers store logs, while auditors verify integrity using the Proof of Past Log and Log Chain.
- An OpenStack implementation found the proposed solution practically feasible to integrate with cloud infrastructure.
- Preserving logs and their proofs increases cloud auditability and can support compliance with SOX and HIPAA.
- Future work will integrate additional logs, evaluate other accumulators, and implement SecLaaS as an OpenStack module.