A File Centric Logger for Monitoring File Access and Transfers Within Cloud Computing Environments

8/12/2019 A File Centric Logger for Monitoring File Access and Transfers Within Cloud Computing Environments

http://slidepdf.com/reader/full/a-file-centric-logger-for-monitoring-file-access-and-transfers-within-cloud 1/7

Flogger: A File-centric Logger for Monitoring File Access and Transfers withinCloud Computing Environments

Ryan K L Ko, Peter Jagadpramana, Bu Sung LeeCloud and Security Lab

HP Laboratories Singapore{ryan.ko | peter.jagadpramana | francis.lee}@hp.com

Abstract — Trust is one of the main obstacles to widespreadCloud adoption. In order to increase trust in Cloud computing,we need to increase transparency and accountability of data inthe Cloud for both enterprises and end-users. However,current system tools are unable to log file accesses andtransfers effectively within a Cloud environment. In this paper,we present Flogger, a novel file-centric logger suitable for bothprivate and public Cloud environments. Flogger records file-centric access and transfer information from within the kernelspaces of both virtual machines (VMs) and physical machines

(PMs) in the Cloud, thus giving full transparency of the entiredata landscape in the Cloud. With Flogger, services can bebuilt above it to provide Cloud providers, end-users andregulators with the relevant provenance, e.g. a tool for an end-user to track whether his/ her file was ‘touched’ by anunauthorized user. We present the initial developments ofFlogger, and interesting results from our experiments. We alsopresent compelling future work that will shape the beginningsof a new logging paradigm: distributed VM/ PM file-centriclogging.

Keywords- Cloud computing; logging; auditability;accountability; trust in Cloud computing; trusted Cloud; Cloudcomputing security; file-centric logs; file-centric loggingmechanisms; detective mechanisms.

I. I NTRODUCTION

Trust is one of the main obstacles to widespread CloudComputing adoption. In order to increase trust in CloudComputing, there are both preventive and detective measures[1]. While many Cloud Computing service providers arefocusing on preventive measures (e.g. better firewalls,stronger encryption, etc), few are focusing on increasing theaccountability and transparency of their Clouds via detectivemechanisms (e.g. logging, reports for end-user self forensics)[2].

With Cloud computing removing the need for end-usersto own systems, we also experience a change in mindset,

from a focus on systems security to a focus on data securityand protection. There is a need to know the “ who, what,where, when, how and why” of data movements in theCloud. This is made even more urgent with the impendingdata explosion [3], and the dawn of the so-called ‘fourth

paradigm’ [3, 4] described by the late Microsoft researcherJim Gray.

With the need for detective measures and the change infocus to data security and protection, comes a demand for arobust security tools which will enable end-users, Cloudcomputing service providers, administrators of Cloud

services, and even regulators to inspect, monitor and analyzethe trends of data accesses and movements within the large-scale Cloud computing environment from a single point ofview. However, are current detective mechanisms ready forthis change in paradigm? We begin by analyzing the currentstate of the art:

II. R ELATED WORK

A. User Space Centralized File System Call MonitorIn traditional one-system or local area network (LAN)

environments, it is common to find user-space filemonitoring tools or extensions of file systems (e.g. iNotify[5], swatch [6], file alteration monitors (FAM) [7]) to bewidely used for monitoring the single- or multiple-fileactivities within a single machine. Tools are also availablefor monitoring packets in networks (e.g. snort [8]). Withlarge scales and heavy usage of virtualization technologies inCloud computing, such tools are insufficient to provide anover-arching view for monitoring files across both virtualmachines (VMs) and physical machines (PMs). Moreover,these applications are usually housed within the user space,leaving them vulnerable to user space attacks.

B. File Integrity Checkers as Intrusion DetectionFile integrity checkers such as TripWire inspect for

changes to the files in the systems by checking against a baseline hash-key database which is regularly updated withthe latest hash keys of the files within a system. Such animplementation is not scalable for the Cloud as there is ahigh volume of access, i.e. the need to regularly update thekey database is not feasible. Furthermore, these tools do not

provide a history of the file changes. Hence, while they areable to identify which files have changed, they are unable toexplain the history of what actually happened to the files.Such limitation is not desirable for forensics in the context ofthe Cloud.

C. Virtual Environment MonitorsWith the rise in adoption of virtualization technologies

especially in private Clouds, software such as the HyTrustAppliance [9] are starting to become more prominent. Thesetools enable administrators to regulate the access rights andto have an overview of the activities and consolidation ofcommon system logs for all virtual machines. However, thisvisibility of the virtual layer is still not the full transparencyrequested by end-users [10] surveyed by the FujitsuResearch Institute, which states that 88% of these users want

2011 International Joint Conference of IEEE TrustCom-11/IEEE ICESS-11/FCST-11

978-0-7695-4600-1/11 $26.00 © 2011 IEEEDOI 10.1109/TrustCom.2011.100

765



to know ‘exactly what goes on’ in the physical servershosting the guest machines.

D. Cloud Systems Health and Performance MonitoringWhen there is mention of monitoring, there is a current

emphasis of monitoring the server performance in Clouds.Such a focus on system monitoring is not totally aligned to

the actual needs of users. Despite having color schemes,visualizations and attractive dashboards, tools such asVMWare vFabric Hyperic [11] and CloudKick [12] are stillunable to offer the crucial need of monitoring datamovements and transfers in the Cloud.

III. NEW BREED OF LOGGERS R EQUIRED

It is now evident from observing the limitations of thestate-of-the-art that we need the following necessaryrequirements for effective monitoring of data in the Cloud:

Transcend VM/ PM - It must be in kernel space, andmust be able to transcend both virtual and physicalspaces in the Cloud, providing full transparency of alloperations in the Cloud.

Provenance - It must provide a full or a summarized/concise provenance of data life cycles and transfers inthe Cloud. This is also in tandem with the increase inthe emphasis of data governance [13] andaccountability [1].

Single Auditable View - It must be able to provide asingle consolidated report for inspection.

Efficient storage - It must be efficient in both shortterm storage and long term archival.

Analytics – It must provide auditing features to enablestrong analytics and quick observations of footprintsof file activities and transfers.

With the above list in mind, we propose Flogger (shortfor File-Centric Logger), a novel file-centric logger that can

be implemented in both VM and PM kernels in a non-invasive manner within nodes in the Cloud.

IV. FLOGGER - ARCHITECTURE AND DESIGN

A. Flogger Addresses the System Layer of the TrustCloud FrameworkFlogger addresses the needs of system layer within the

TrustCloud Framework [1]. TrustCloud is a layeredframework describing the different layers of granularity forCloud accountability. The System Layer in the frameworkhighlighted the importance of monitoring and auditingcontainers of data (e.g. files) within and out of the Cloud.

With the foundational System Layer, we can then studymovement and changes of data within and across files (DataLayer), and also workflows and data flows (WorkflowLayer)– thus giving full provenance of data in the Cloud andin compliance to the Law/ Regulation Layer and the PoliciesLayer. Further descriptions of issues related to these layers ofaccountability are described in [1].

B. Flogger Components and ArchitectureFigure 1 shows Floggers and their accompanying

components, and demonstrates the underlying mechanisms

capturing file actions and movements from the underlyingkernel space (depicted by the numeric sequence in Figure 1).A simple example of the resulting file-centric log (in short,“flog”) captured by both a VM and its host PM is shown inFigure 2.

1) ComponentsThe typical implementation consists of the followingcomponents (See Figure 1):

Flogger (Linux) – A Linux Loadable KernelModule (LKM) running on VM which interceptsfile and network operations and writes the eventsas VM flogs.

Flogger (Windows) – A Windows Device Driverrunning on PM which intercepts file operations andwrites the events as PM flogs.

Components accompanying Flogger- File Sender Client program running on VM which

transfers the VM log files from VM to PM via adirect communication channel.

- File Sender daemon running on VM which

regularly executes the File Sender Client program.- File Sender Server program running on host PMs

which receives the VM log files sent by the FileSender Client program.

- Two Database Loader daemons running on PM.The first one regularly loads the VM log files into aremote database server. The second one regularlyloads the PM log files into the same remotedatabase server.

With these components, we can then view and analyze theconsolidated VM and PM flogs using any database front-end tools or in spreadsheet tools reading comma-separatedvalue (CSV)/ tab-separated value (TSV) files.

2) How Flogger WorksFlogger captures file-centric logs ( a.k.a. flogs) via the

following steps (with reference to the labels in Figure 1):

Step 1: Linux Flogger/ Windows Flogger intercept every fileaccess in the VMs. The Floggers capture the followinginformation (Flog Subset A) (non-exhaustive list):

VM Accessed file name and full path e.g./home/users/john/docs/sensitive.txt

VM File access date/time VM IP address VM MAC address Machine type i.e. VM or PM UID of file owner of the accessed file GID of file owner of the accessed file UID of process owner who accessed the file GID of process owner who accessed the file Action done to accessed file e.g. Create, Read,

Write, Socket (Send Message), Socket (ReceiveMessage), Delete

It is important to note that the list in Flog Subset A is notexhaustive and more attributes are added to make the systemmore robust, e.g. more timestamps.

766





Table 1: Extracted columns from flogs of Scenario 1No.(Includedfor thispaper) filename full_path

uid

gid

file_ user name pid p_uid

process_username vm_ip4 vm_ip6 vm_mac

vm_interface date_time

timeval_sec

timeval_usec

vm_ip4_raw action

…

1PatentDisclosure.

txt

/shared/doc/PatentDisclosure.tx

t

502

502 alice 24436 502 alice

10.252.250.1

fe80000000000000020c29fffec

5bc4400:0c:29:c

5:bc:44 eth0

2011-06-2709:55:24+0

81309139727 738618

184351233 Create

…

2PatentDisclosure.

txt


t

502


10.252.250.1

fe80000000000000020c29fffec

5bc4400:0c:29:c

5:bc:44 eth0

2011-06-2709:55:24+0

81309139727 739308

184351233 Read

…

3PatentDisclosure.

txt


t

502


10.252.250.1

fe80000000000000020c29fffec

5bc4400:0c:29:c

5:bc:44 eth0

2011-06-2709:56:47+0

81309139810 672980

184351233 Read

…

4PatentDisclosure.

txt


t

502


10.252.250.1

fe80000000000000020c29fffec

5bc4400:0c:29:c

5:bc:44 eth0

2011-06-2709:57:00+0

81309139823 808734

184351233 Write

…

5PatentDisclosure.

txt


t

502


10.252.250.1

fe80000000000000020c29fffec

5bc4400:0c:29:c

5:bc:44 eth0

2011-06-2709:57:00+0

81309139823 836413

184351233 Read

…

6PatentDisclosure.

txt


t

502


10.252.250.1

fe80000000000000020c29fffec

5bc4400:0c:29:c

5:bc:44 eth0

2011-06-2709:57:00+0

81309139823 837186

184351233

Rename(Old File)

…

7PatentDisclosure.

txt~


t~

502


10.252.250.1

fe80000000000000020c29fffec

5bc4400:0c:29:c

5:bc:44 eth0

2011-06-2709:57:00+0

81309139823 837735

184351233

Rename(New File)

…

8PatentDi

sclosure.txt

/shared/doc/PatentDi

sclosure.txt

5

02

5


10.252.250.1

fe800000000000000

20c29fffec5bc44

00:0c:29:c5:bc:44 eth0

2011-06-27

09:57:00+08

1309139823 841338

184351233

Rename(New File)

…

9PatentDisclosure.

txt


t

502


10.252.250.1

fe80000000000000020c29fffec

5bc4400:0c:29:c

5:bc:44 eth0

2011-06-2709:57:00+0

81309139823 844019

184351233 Read

…

10PatentDisclosure.

txt


t

502


10.252.250.1

fe80000000000000020c29fffec

5bc4400:0c:29:c

5:bc:44 eth0

2011-06-2709:58:34+0

81309139917 782164

184351233 Read

…

11PatentDisclosure.

txt


t

502


10.252.250.1

fe80000000000000020c29fffec

5bc4400:0c:29:c

5:bc:44 eth0

2011-06-2709:58:50+0

81309139933 983277

184351233 Read

…

12PatentDisclosure.

txt


t

502

503 alice 24631 503 bob

10.252.250.1

fe80000000000000020c29fffec

5bc4400:0c:29:c

5:bc:44 eth0

2011-06-2710:00:34+0

81309140037 509728

184351233 Read

…

Step 1’ : Just like VMs, PMs also have Floggers whichintercept the PMs file system calls and then stores them inthe Data Store.

Step 2: After the file life-cycle related information arecaptured, they are sent to the host PM. The VM Floggerdirectly sends the captured information (Flog Subset A) toPM Receiver Daemon via a Communication Channel

between VM and PM. The Communication Channel isspecial mechanism available on typical hypervisors whichenable a serial cable-like communication between VMs andPMs. It does not involve networking transfers. Hence, noVM Flogger transfer Flogs to PM File Sender Servers vianetwork transfers. This increases the security of the transferof Flogs.

Step 3: VM File Sender Daemon regularly executes the FileSender Client which reads the File Access Details (FlogSubset A) and sends them to the PM via the CommunicationChannel between VM and PM.

Step 4: PM File Sender Server receives the File AccessDetails (Flog Subset A) from VM File Sender Client via theCommunication Channel between VM and PM.

Step 5: PM Flogger generates other PM information (FlogSubset B), for example (but not limited to):

PM IP address PM MAC address

Step 6: The PM Flogger sends Subset B to PM File SenderServer. Subsets A & B will give users a consolidated set ofinformation (i.e. Flog) which can pinpoint the VMs and PMsinvolved in each file’s life cycle to enable full accountabilityof distributed VM and PM architectures, e.g. Cloudcomputing.

Step 7: Within the PM Subnet, the PM Database loaderdaemons write the joint/ consolidated information (bothSubset A & Subset B) to a Data Store e.g. database for futuredata mining and reporting. Note that all the consolidation ofthe Flogs across PMs into the Data Store take place only inthe PM Subnet. Users in the VM Subnet should have no

768





Figures 5 and 6 below depict the Socket (Send Message)and Socket (Receive Message) respectively being captured inthe Linux kernel message log.

Figure 5. Scenario 2 Sender Kernel Message Log File

Figure 6. Scenario 2 Receiver Kernel Message Log File

C. Provenance from LogsFrom the two scenarios, we can now visualize the data

provenance potential information that Floggers can providefor Cloud end-users, administrators and even regulators.Virtual machine file access and transfers are logged withtheir corresponding file system calls in the physical hosts.Such correlation gives a good transparency of the location offiles within a Cloud, and analytical tools can be built over

these flogs to let people answer questions such as “Are myfiles really deleted in this Cloud?” or “Can I see who hasaccessed my sensitive file in this Cloud?”.

VI. CURRENT AND FUTURE WORK

The development of Floggers and the successfulconsolidation of simultaneously-generated VM and PM file-centric logs addressed the need for higher Cloudaccountability and transparency, but also revealed limitationsand several compelling future research directions:

A. Integrity and Security of the Logger and LogsAt the moment, flogs are passed securely down the

communication channels from the VMs to their host PMs.As such, there is no network transfer of flogs at the virtuallayer and the VM subnet (see Figure 1). Flogs consolidatedat the PMs are sent to the data store within the PM subnet.Security of the Floggers also depends on the integrity of themachine kernels in the Cloud. However, the assumption ofthe kernel integrity is insufficient. Vulnerabilities may existwhen PMs are transferring logs to the database storage.Authentication or simple client puzzles-like protocols

between PMs and the storage may be introduced when flogsare transferred. There is also a need for flogs to remaintamper-proof and immutable. These requirements are ourcurrent top priorities.

B. Scale and Log Data Size ExplosionCompared to system-centric logs (e.g. event logs, system

logs, or user account activity logs), file-centric logs (flogs)grow at a relatively higher rate. In one of our experiments, afile created in a word processing application generated up toapproximately 29,000 file activities within 30 minutes eventhough user-triggered activities (e.g. write) are kept to theminimum. It was later revealed that its automatic backup

features was enabled, causing it to be extremely chatty.We are also aware that the prospect of flogs outgrowingthe size of the actual files to be tracked is a realistic one.However, the concerns of the exponential growth of logsmay be mitigated by our current attempts in exploring tieredstorage and archival [1], de-duplication and summarizationtechniques.

C. Rules for Application Footprints Captured in FlogsIn our experiment, we also note an interesting

observation of recurring footprints for different types ofsoftware. This opens the possibility of creating heuristics andrules for identification of anomalies and attacks in the Cloud.

D. VisualizationsWith the large amount of data collected, it is perhaps a

good idea to formulate different types of useful exploratoryand presentation visualizations for the discovery and

presentation of notable trends and patterns in the flogs.Visualization needs for end-users, administrators andregulators are different. For example, Cloud service

providers may only offer end-users knowledge about thehigh-level geography without revealing specific data centerslocations. End-users can still know if their data has violated

770



cross-geography policies of data transfers. On the other hand,regulators may be granted special access accounts tovisualize and audit the compliance of full data flows withinthe Cloud.

E. Linkage with Governance, Regulation and Compliance(GRC) needs

With the data accesses and transfers logged by Flogger,automatic auditing and high availability of data flowinformation are now realistic futures in the Cloud. This isalso inline with the vision of the Workflow Layer in theTrustCloud framework[1].

VII. CONCLUDING R EMARKS

In this paper, we emphasized the importance of a file-centric detective measures for increasing trust in the Cloud.We also demonstrated the increase of transparency andaccountability of the Cloud via the novel file-centric loggingmechanisms known as Floggers.

Current system logs only focuses on general systemhealth indicators (e.g. uptimes, processor usage, events, etc).There is no focus on the life cycles of files stored in the filesystems across both VM and PM. Our technique hasaddressed the need for a file-centric logging within networksof PMs hosting multiple-folds of VMs.

Moreover, current system logs are standalones keptwithin each VM or PM, and at best, across multiple VMs orPMs, but never consolidated or managed across both VMand PM simultaneously. There is a need for users to beaware of the exact VMs and the physical locations ofunderlying PMs that they have stored data in. Our technique,Flogger, has addressed this by logging file life-cycle relatedevents on both VMs and their underlying host PMs.

Floggers can be applied into both private and publicCloud computing environments. Because of the service-

oriented nature of Cloud services, Cloud users no longerneed to own and maintain their own PMs, but rather, storetheir information in the Cloud, without the need to beconcerned of the vendors’ server system health indicators.

Our technique will enable system administrators and end-users to audit file life cycles, access and transfer histories.File-centric logs, or flogs, collected by Floggers will alsoenable system administrators and end-users to identify boththe virtual and physical location of original and duplicatefiles to facilitate accountability, IT forensics and tracking ofcriminal activities within a Cloud provider’s servers.

The initial experiments show a lot of promise. Whilethere is much future work involved, we strongly feel that thisis the exciting beginning of the distributed VM/PM file-

centric logging paradigm for Cloud computing.ACKNOWLEDGMENTS

We would like to thank our colleagues MarkusKirchberg, Teck Hooi Lim, Alan Tan, Chun Hui Suen,Ahmed Aneeth, Ahmed Rifau Rasheed, Siani Pearson, and

Miranda Mowbray from the TrustCloud research project [1]for their valuable critique and feedback.

R EFERENCES [1] R.K.L. Ko, P. Jagadpramana, M. Mowbray, S. Pearson, M. Kirchberg, Q. Liang

and B.S. Lee, “TrustCloud - A Framework for Accountability and Trust inCloud Computing,” Proc. IEEE 2nd Cloud Forum for Practitioners (IEEE

ICFP 2011) , IEEE Computer Society, 2011, pp. 1-5.

[2] R.K.L. Ko, B.S. Lee and S. Pearson, “Towards Achieving Accountability,Auditability and Trust in Cloud Computing,” Proc. International workshop onCloud Computing: Architecture, Algorithms and Applications(CloudComp2011) , Springer, 2011, pp. 5-18.

[3] A.J.G. Hey, S. Tansley and K.M. Tolle, The fourth paradigm: data-intensive scientific discovery , Microsoft Research Redmond, WA, 2009.

[4] S. Sakr, A. Liu, D. Batista and M. Alomari, “A Survey of Large Scale DataManagement Approaches in Cloud Environments,” Communications Surveys &Tutorials, IEEE , no. 99, pp. 1-26.

[5] R. Love, “Kernel Korner: Intro to iNotify,” Linux Journal , vol. 2005, no. 139,2005, pp. 8.

[6] S.E. Hansen and E.T. Atkins, “Automated system monitoring and notificationwith swatch,” USENIX Association’s Proceedings of the Seventh SystemsAdministration (LISA VII) Conference, 1993.

[7] Silicon Graphics International Corp, “File Alteration Monitor (FAM) Overview,”2009; http://oss.sgi.com/projects/fam/ .

[8] M. Roesch, “Snort-lightweight intrusion detection for networks,” Proc. 13th Large Installation System Administration Conference (LISA) , 1999, pp. 229– 238.

[9] HyTrust, “HyTrust Appliance,” 2010;http://www.hytrust.com/product/overview/ .

[10] Fujitsu Research Institute, “Personal data in the cloud: A global survey ofconsumer attitudes,” 2010;http://www.fujitsu.com/downloads/SOL/fai/reports/fujitsu_personal-data-in-the-cloud.pdf .

[11] VMWare Hyperic, “Performance Monitoring for Cloud Services,” 2011;http://www.hyperic.com/products/cloud-status-monitoring .

[12] CloudKick, “CloudKick - Cloud Monitoring and Management,” 2011;https:// www.cloudkick.com/ .

[13] Cloud Security Alliance, “Security Guidance for Critical Areas of Focus inCloud Computing V2.16,” 2009; https://cloudsecurityalliance.org/csaguide.pdf.

771

Documents

A File Centric Logger for Monitoring File Access and Transfers Within Cloud Computing Environments