myGrid asset-based security analysis
Victor Tan, Luc Moreau
University of Southampton
Mike Surridge
IT Innovation
myGrid in one slide
• EPSRC pilot project (Manchester, Southampton,
Nottingham, Newcastle, Sheffield, EBI)
• Industrial partners (AZ,Merck,GSK,IBM, SUN, …)
• myGrid aims at providing a personalised
environment for bioinformaticians to perform in
silico experiments
• In-silico experiments operate over the Grid;
resources are geographically distributed and
managed by multiple institutions; necessary tools,
services, and worflows are discovered and invoked
dynamically; this is data intensive grid.
Motivation
•
•
•
Perform security analysis of myGrid
Need to design security architecture
for myGrid
From a project viewpoint, decide
what aspect of security we need to
allocate our resources to
Background
•
Follow standard security engineering
process methodology
1. Define primary purpose and goals of the
project
2. Obtain high-level security requirements
3. Identify assets in project
4. Identify risks posed to assets and the cost of
possible compromise
5. Selection of security technologies on the basis
of a cost benefit analysis
6. Definition of operational responsibilities:
development, maintenance and response.
Background
• A two steps approach:
– Questionnaire 1 to identify high-level
project goals and high-level security
requirements
– Questionnaire 2 to identify project assets,
risks, and technological solutions.
Questionnaire 1 scope and structure
•
Scope of Questionnaire 1
1. Define primary purpose and goals of the
project
2. Obtain high-level security requirements
•
Divided into 6 main parts
1.
2.
3.
4.
5.
6.
Purpose of the project
Deployment and management
Security management and roles
Organizational issues
myGrid communities
Legal issues
Purpose of the project (Part 1)
• Three distinct viewpoints for operation of
myGrid
– Bioinformatics
– Grid computing
– Industrial use
• For each viewpoint, identify the primary goal
–
–
–
–
Research tool
One-off-demo
Proof-of-concept
Operational use
Purpose of the project (Part 1)
• For each viewpoint, identify the level of risk
associated with the compromise of:
– User identity
– Data integrity and confidentiality
– Host machines
• Explore the longevity of the myGrid
components and services after final report
writing
– Handling of code base
– Management of code base and services
Summary of survey (Part 1)
•
The majority opinion is that the primary
goal of myGrid from all viewpoints is a
proof of concept system.
•
The overall intent is on demonstrating
proof of concept for myGrid from the
aspect of functionality rather than
security
•
The risk involved in the various areas of
security are generally classified as high
risk
Summary of survey (Part 1)
•
A security architecture is seen as
something that has to be done as
opposed to a possible venue for exploring
or researching new security concepts.
•
Most believe that maintenance of the code
base would be undertaken by either the
developers or the open middleware
institute OMII, with little likelihood of it
being maintained in a commercial
context.
Deployment and management (Part 2)
• myGrid services to be deployed primarily as
– Open vs closed systems
– Loosely bound / autonomous vs tightly bound /
centralized
• Gauge the extent of involvement of the user
in using myGrid components:
–
–
–
–
–
Downloading
Installation
Deployment
Upgrade
Maintenance
Summary of survey (Part 2)
•
•
•
•
The majority feel that myGrid should be
operated as an open system which
permits services to join and interact with
it dynamically during the duration of its
operation
Most also view myGrid as a
confederation of loosely bound
services which are largely autonomous.
With regards to user involvement, the
majority are of the opinion that
involvement should be minimal.
There is a desire to delegate responsibility
of all management issues to system
managers
Security management and roles (Part 3)
• Determine which of the three basic roles: end user,
system manager and group manager would be
involved in:
–
–
–
–
–
–
Patching software
Publishing security related news
Keeping track of security compromises
Registering and issuing certificates to new users
Firewall operation
Alerting and responding to the Computer Emergency Response
Team
– Setting an update policy for updating software
– Setting a usage policy governing the use of the service
– Setting a security policy dictating how security issues are
handled
• Integration / reconciliation of conflicting security
policies of different participating organizations
Summary of survey (Part 3)
•
For the activities of setting usage
policies and security policies, the group
manager was identified as the most
suitable role.
•
For the rest of the security activities
(patching software, publishing security
related news, etc), most believe that the
system manager should be responsible
•
In all instances, the amount of user
involvement is again minimal.
Summary of survey (Part 3)
•
Most believe that the issue of integrating
potential conflicts between different
security policies should not be addressed
as it is too broad and complex to be
resolved within the timeframe of the
project
•
Focus should be on more security issues
in the small such as authentication,
integrity, etc.
Summary of survey (Part 3)
•
Security requirements is understood for each
individual myGrid component but how these
requirements impact and affect each other
when components interact is neither known nor
is there any desire to examine it in depth.
•
The fundamental view to emerge from this is a
lack of desire to define in detail an overarching
view of security in myGrid.
•
But, this seems to be a contradiction, if we expect
a system manager to deploy a myGrid system,
without indication of what its security implication.
•
“It does what it says on the tin” … BUT “nothing is
written on the tin”.
Organizational issues (Part 4)
• Nature of impact on these following
organizations in the event a myGrid
deployment is compromised
– Institution / department
– Computing Services
– JANET
• Identify security requirements that the
myGrid project can ignore and leave to the
deploying organisation to address
• Definition of what constitutes proper usage
of myGrid resources
Summary of survey (Part 4)
•
Most believe that the
institution/department and the
computing services would be seriously
affected in the event of a compromise in
the security of the deployment of myGrid
•
The general consensus is that the myGrid
project should try to avoid addressing
the majority of security requirements,
with the responsibility being delegated or
made clear to the deploying organization.
Summary of survey (Part 4)
•
For pharma companies, myGrid is seen to
be targeted for internal deployment
where it is assumed an existing security
infrastructure is already provided for
myGrid to fit into.
•
There is also no clear opinion with regards
to defining the nature and proper usage
of a myGrid resource.
myGrid communities (Part 5)
• Implications on security issues that
interactions with the following entities may
entail:
– myGrid communities
ƒ myGrid pharmaceutical company partners (AZ, GSK,
Merck, etc).
ƒ World wide bioinformatics community.
ƒ UK e-science community
ƒ Grid community
– Other grid projects
Summary of survey (Part 5)
• There is a clear desire to interact and
communicate with other communities.
• For pharmaceutical companies,
concerns include:
– ensuring privacy of data
– companies having their own security
infrastructure into which myGrid can be
fitted in
– supply of code being accompanied with
denial of liability.
Summary of survey (Part 5)
•
There was an acknowledgment of a need
to adhere to existing security standards or
community practices such as the
eScience PKI or GSI.
•
Dealing with copyrighted data and
obtaining permission for data distribution
or storage are also possible areas of
concern.
•
Some of the projects named are MIASGrid, OGSI and CLEF, but no new security
risk was explicitly returned.
Legal issues (Part 6)
• Understand considerations related to legal
constraints that govern privacy and confidentiality of
data (Data Protection Act 1998, Human Rights Act
1998, English Common Law and/or specific
contracts with organisations employing myGrid
services)
– Availability of a registered data controller to enforce legal
requirements
– Obtaining user’s consent on processing personal
information
– Permitting a user to access and modify his personal details
– Preventing exposure of a user’s personal information for
the purposes of marketing
– Allowing a user to object to the processing of his personal
information in a specific manner
Legal issues (Part 6)
•
Discuss how aspects myGrid research
focus (provenance, notification of
change and personalisation) can be
handled with regards to these legal
constraints
Summary of survey (Part 6)
• There is a general awareness of the
importance of:
– obtaining a user’s consent before collating or
processing personal information
– allowing a user to object to processing of
personal information
• Majority of respondents are still unclear
about other legal obligations affecting the
project with impact on other associated
issues of privacy.
Summary of survey (Part 6)
• There is an appreciation of the various
security requirements related to
provenance:
– Provenance security requirements include user authentication,
establishment of authorship, mutual authentication, non
repudiation, encryption and access control, tracking of user
actions
– Provenance data might provide audit information to detect when
users are trying to exceed the rights they have been granted,
– A possible consideration is that users of myGrid may have to
declare the use that can be made of records of their actions in a
provenance record
– Controlling access for users to provenance records
Inconsistencies in response
•
In Part 1 of the survey (goals of the project), the
generally high perception of risks (e.g. bad
authentication, compromise of data) appears to
contradict the intended goal of myGrid (i.e
security is usually not important in a system
designated to demonstrate proof-of-concept)
•
This may have possibly resulted from people
responding in a way that they typically perceive
security concerns should be viewed as (i.e.
high risk) rather than actual assessment of the
security needs that correlate with their desired
use of myGrid
Inconsistencies in response
•
In Part 2 of the survey (deployment of the
system), the responses with regards to the
open/closed and loosely-bound/tightly
bound views indicated that some
respondents did not seem to understand
that these options were mutually
exclusive
•
This could be due to the fact that some
feel that myGrid can be deployed in
modes of operation that reflect a
combination of these characteristics
Inconsistencies in response
•
In Part 3 of the survey (security management and
roles), the majority felt that the system manager
should be responsible for a large portion of the
security responsibilities.
•
However the lack of desire to produce a general
overarching view of security makes it difficult for
the system manager of the deploying organization
to manage myGrid security effectively
•
This could be due to the fact that the majority of
respondents do not believe there are significant
security problems that could arise from interaction
from the various myGrid components together.
Inconsistencies in response
•
In Part 4 of the survey (organizational issues), the
majority feel that many important security
requirements should be delegated to the
deploying organization
•
Again this reflects the desire to delegate security
responsibility to the system manager of the
deploying organization without any consideration
of how difficult this task may be for him or her
without some form of overarching security
overview or policy
Questionnaire 1: Overall summary
•Purpose of myGrid – proof-of-concept
•myGrid viewed as an open and loosely coupled system
•Security responsibilities borne mainly by systems manager
•No desire to define overarching security policy or overview
•Consideration of security requirements should be left to deploying
organization
•Desire to interact with other communities and acknowledgement of
need to adhere to existing security standards
•General awareness of some legal rights of a user and how this
affects activities like provenance
Next step
•
The next stage in the security engineering
process methodology is to perform an asset
based risk assessment, which will require the
assessment and/or quantification of the threats
associated with each myGrid project asset
•
This assessment will be performed through the
distribution of another questionnaire to
relevant members of the myGrid project
•
This assessment will be done with respect to the
context of a given role (e.g. end user,
researcher, support staff, etc) and will be based
on the premise that myGrid would be deployed in
a proof of concept scenario
Next step
•
Such a demonstration will run over a predefined
period of time and may require re-configuration
of existing security policies in the computing
departments of the participating organizations.
•
The ultimate goal would be to produce a bestpractice document that can identify the actual
threats involved with each asset in such a
scenario.
Questionnaire 2: Scope and background
•
Scope of Questionnaire 2
1. Identify risks posed to assets in project
and the cost of possible compromise
2. Selection of appropriate security
technologies as possible defences on
the basis of a cost benefit analysis
Questionnaire 2 premises
• Based on two premises obtained from
the results of the preceding survey:
– Assessment done with respect to the
context of a given role (e.g. end user,
researcher, support staff, etc)
– myGrid would be deployed in a proof of
concept scenario that will run over a
predefined period of time and may require
re-configuration of existing security
policies in the computing departments of
the participating organisations
Questionnaire 2 structure
•
Establish the context and time frame for the roles
involved in the proof of concept deployment.
•
5 main roles defined and the various assets and
threats associated with them are outlined
1.
2.
3.
4.
5.
•
Support staff
End users
Research staff
Service providers
Project as a whole (combination of all 4)
Asset risk cost analysis section identifies the
various defences which are capable of addressing
the related threats
Support staff (Part 1)
• System administrators and the support staff
for the machines and networks will be
involved in the setting up, hosting and
maintenance of the various myGrid
components
• The assets involved are:
–
–
–
–
Technical skills and expertise of the support staff
Reputation and respect for the support staff.
Workstations hosting the myGrid clients
Servers hosting myGrid services
End Users (Part 2)
• End users will interact with the various
myGrid services by initiating workflows
through the various clients (workbench,
service browser, etc)
• The assets involved are:
– Identity credentials (used in authenticating the
users properly to the system)
– Workflows
– Workflow data
– Provenance information
Researchers (Part 3)
• The researchers are the principal
investigators, work package leaders
and research assistants in the various
myGrid academic groups that are
involved in the development and
deployment of the various myGrid
services, databases and clients.
• The main asset is the reputation and
respect for the researchers.
Service Providers (Part 4)
• The service providers are the various
participating groups that will provide
the data (genome sequences, lab
results, etc) that are be used in the
execution of workflows.
• The main asset here would be the data
provided and their resources.
Overall (Part 5)
• Refers to the collective assets and
risks faced by the myGrid project team
as a whole.
• The assets involved are:
– Technical skills and expertise of the
project members
– Reputation and respect for the project
and its work.
• Questionnaire asks respondents
– About other assets,
– How high the cost of their compromise
would be,
– By what threats they would be
compromised.
• We felt that a full cost analysis was not
practical, but indication of “low”,
“medium”, “high” cost was enough for
our purpose.
Asset Risk Cost Analysis (Part 6)
• Contrasts the estimated costs of the various
threats identified in the previous sections
with the estimated costs of the defences
required to cope with them satisfactorily.
• The following defences are identified
initially:
–
–
–
–
–
–
–
–
–
–
–
Firewalls
X509 certificates and PKI infrastructure:
Proxy certificates
Encryption packages/algorithms
Secure protocol usage (SSL, HTTPS, WS-Security)
Staff training on security procedures
Security policies (access control based on security credentials)
Operational policies (on using myGrid services)
System patching
Effective publicity
Staff identification (name tags, etc)
Conclusion
• Few new threats, assets or defences were
identified – this may indicate lack of interest in
considering the security issue in greater depth as of
yet
• Of the relevant threats identified, the majority were
rated as posing a high risk to their associated
assets – this might indicate that the risks listed were
perceived to be relevant to the concerns of the
questionnaire respondents
• Most respondents associated at least one risk with
each given asset, and sometimes associated more
risks with a specific asset than the initial predefined
ones
• Defences – difficulty to assess the cost
• http://twiki.mygrid.org.uk/twiki/bin/view/
Mygrid/SecurityArchitecture
Survey Participants
• Matthew Addis (IT Innovation), Syd Chapman
(IBM), B Donnelly (GeneticXchange), James
Fleming (EPSRC), Rob Gaizauskas (Sheffield),
Carole Goble (Manchester), Chris Greenhalgh
(Nottingham), Bernard Horan (SUN), Michael Lees
(Network Inference), Robin McEntire (GSK), Luc
Moreau (Southampton), Matthew Murray
(Epistemics), Peter Rice (EBI), Nick Sharman
(Manchester), Luca Toldo (Merck), Brian Warboys
(Manchester), Paul Watson (Newcastle), Anne
Westcott (AstraZeneca)
www.mygrid.org.uk
m