Trusted Logging for Grid Computing

1
Trusted Logging for Grid Computing

• Jun Ho Huh and Andrew Martin
• Oxford University

2
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

3
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.

4
Abstract View of the Grid

• Standard external services (ES) manage middleware
  operations e.g. user authentication, data access
  and enable communication between different nodes.

5
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.

6
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.

7
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.

8
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.
• Its 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)

9
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.

10
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.

11
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.

12
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 clients system might tamper
  with the reconciled logs to make false
  accusations.

13
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.

14
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.

15
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.

16
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.

17
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.

18
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.

19
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.

20
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 its
  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.

21
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).

22
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.

23
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.

24
Secure Logging Infrastructure
25
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.