Trusted Logging for Grid
Computing
Jun Ho Huh and Andrew Martin
Oxford University
Contents
Secure logging in a grid environment
Motivational examples
Existing solutions and gap analysis
Towards a common logging
infrastructure for the grid
 A trusted logging architecture
 Future Work/Conclusion




Secure Logging in a Grid
Environment
 Logging services:


facilitate the communication and recording of diagnostic
audit trails
are used to detect security violations, for dynamic
access control, forensic examination, intrusion detection,
financial and business audits etc.
 What is the Grid?
 a system that coordinates resources that are not
subject to centralised control; that uses
standard, open, general-purpose protocols and
interfaces.
Abstract View of the Grid
 Standard external services (ES) manage middleware
operations e.g. user authentication, data access; and
enable communication between different nodes.
Secure Logging in a Grid
Environment

Grid nodes spanning multiple administrative domains
makes it very difficult problem in the grid:



services and the associated logs are stored in different formats
different domains within a specific grid will have different
standards, policies for retention and so forth.
ad hoc, difficult to browse and analyse these logs.

Log data is highly sensitive, and only processed subsets
may be released

Reconciliation of logs from different sources is needed, but
neither trusts the other to see the raw data.

Logging services and logs are inconsistent; a need for a
common approach to reconstruct the thread of work
securely in a distributed environment.
Motivational Examples
 Healthcare Grid
 Many data grids are being interconnected
 to facilitate the better provision of clinical
information
 to enable collection and analysis of data for
scientific purposes.
 A form of ‘traffic flow’ analysis may itself yield
much information about the patient and/or their
clinical data, so the access logs themselves are
highly privileged.
Motivational Examples
 A malicious researcher may try to discover
personal information about patients from
cumulating the history of accessed data.
 Each site needs to record what the user has
seen so far, update its data access control
mechanisms.
 In the grid an attacker could join set of
records returned from multiple sites.
Motivational Example
 A distributed audit approach:


patterns of behaviour across multiple domains will be
detected by combining audit logs across them;
requires each site to grant permissions to remote
individuals to view its logs.
 It’s unlikely to happen due to complications of
negotiating trust in the dynamic grid environment.
 Allow a server to collect and reconcile distributed
authorisation decisions (in form of audit trails)
Motivational Examples
 Monitorability of Service-Level Agreements
(SLAs)
 Provision of SLAs and ensuring their
monitorability with TC.
 Client receives no response for a service (which
they have entered into a SLA) within the agreed
interval of time  complains to the service
provider  service provider argues that no
request was received, produces evidential log of
requests.
 No way for the client to find out the truth.
Motivational Examples
 Problem: this type of SLA is defined in
terms of events the client cannot monitor;
must take the word of the provider.
 Need for trustworthy logging and reporting
services in which all stakeholders can trust
another to record, report and analyse the
actual transmission of requests and
responses accurately.
Use Case Example
 Service provider wishes to produce a trustworthy report
on a log of requests to claim that no service request was
received from the client.
Possible Threats
 The service provider (or the client) may
insert arbitrary logs, modify or delete
request/response logs from the log storage,
and deliver fabricated evidence.
 The service provider might try to tamper with
log collection and migration services to
deliver fabricated results.
 A user logged in the client’s system might
tamper with the reconciled logs to make false
accusations.
Existing Solutions & A Gap Analysis
 Not much focus on how logs are securely
generated and stored:
 NetLogger Toolkit: provides client application
libraries (C, Java, Python APIs) for generating
NetLogger log messages in a common format.
 relies on the application developers to write
logging code.
 No security controls to verify the log
generators and the log data:
 Xenlog: Xen based logging solution; the logging
service (Dom0) completely trusts the shared
memory to always deliver trustworthy logs.
Existing Solutions & A Gap Analysis
 No attempt to protect the
confidentiality and the integrity of the
log data upon their transmission,
collection and reconciliation
 No encryption or signing procedures for
logs in Xenlog and NetLogger.
Towards a Common Logging
Infrastructure for the Grid
 Motivational examples have in
common requirements upon:
 Integrity and accuracy of log information
 Confidentiality of the logged data.
 Trustworthy analysis and reconciliation
of log data.
 Interoperability of the logging services,
the logged data and the policies for
accessing them.
Towards a Common Logging
Infrastructure for the Grid
 Trusted logging requirements
 to fill the gaps
 to facilitate production and analysis of log data
in the grid with strong guarantees of their
security.
 Secure Logging Service
 needs to be deployed independently from parent
application, in a strongly isolated compartment.
 small, simple software component with relatively
static code-base.
 needs to verify the log generators.
Towards a Common Logging
Infrastructure for the Grid
 Authorisation Policy Management for Logs
 distributed access requests for logs need to be
controlled with authorisation policy
enforcements
 to prevent unauthorised access to sensitive logs,
and from inference attacks.
 Secure Log Migration Service
 complex grid middleware services cannot be
relied upon to perform trusted operations.
 instead, security controls required for safe log
data transfer need to operate in this service.
 data flow encryption and signing requirements.
Towards a Common Logging
Infrastructure for the Grid
 Trustworthy Reconciliation Service
 requires each site to build trust with others, and
grant permissions to view their logs.
 Log owners, by attesting this service, need to be
assured that
 their logs will be safeguarded from
compromise during reconciliation.
 robust security controls are enforced upon
collection and reconciliation of the logs.
Towards a Common Logging
Infrastructure for the Grid
 Blind analysis of the Logs
 A healthcare grid --- hospitals have agreed to
share their logs for intrusion detection.
 However, they are unwilling to let the others to
see the raw data, only let part of it to be seen.
 log owners need to be assured that their logs
will be revealed to an extent that has been
agreed (or stated in restriction policies).
 blind analysis of the collected logs required:
developers only see the running application, and
the end results.
A Trusted Logging Architecture

A novel logging architecture for the grid using trusted
computing and virtualization capabilities.

Trusted Computing (TC)



remote sealing: sealing the data so that it’s only available to a
remote host running in a particular software configuration.
remote attestation: proving to a third party that a remote
device is in a particular software state.
TC used in a virtualised environment where physical host is
segmented into strongly isolated compartments:


to make remote attestation feasible (memory protection)
to limit the impact of any vulnerability in attested code.
A Trusted Logging Architecture

All log security functions enforced by log security manager, log transit components, log
analysis manager.

Small number of back-end driver VMs are responsible for generating all trusted logging
requests (log transit).
A Trusted Logging Architecture
 A log access grid job is always executed in
a per-user log access VM with trusted
middleware services and expected security
configurations:
 log owners perspective: isolation of malicious
jobs; trusted services always govern
authorisation policy enforcements, encryption of
logs
 users perspective: trusted code runs unmodified
on a secure VM; logs accessed with trusted
middleware stack; remote attestation of log
access VM ensures integrity of logs.
Secure Logging Infrastructure
 In Xen only Domain 0 (privileged VM) and other driver
domains have access to physical hardware.
 Single point of access for all physical devices: where
log transit is deployed.
 Log transit components run in a much simpler and
safer environment.
 Only the privileged domains have control over how
and when trusted logging requests are triggered; log
generator verification becomes much easier to
manage in the grid.
Secure Logging Infrastructure
Future Work
 Next step is to design and construct
prototype implementations of some of
these services with TC and
Virtualisation technologies.
 Develop a trustworthy log
reconciliation infrastructure based on
the requirements and the identified
compartments.