mygrid asset-based security analysis victor tan, luc moreau university of southampton mike surridge...

myGrid asset-based security analysis

Victor Tan, Luc MoreauUniversity of Southampton

Mike SurridgeIT 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 requirements3. Identify assets in project4. Identify risks posed to assets and the cost of

possible compromise5. Selection of security technologies on the basis

of a cost benefit analysis6. 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 11. Define primary purpose and goals of the

project2. Obtain high-level security requirements

• Divided into 6 main parts1. Purpose of the project 2. Deployment and management3. Security management and roles4. Organizational issues5. myGrid communities6. 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


• 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


• 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


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


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


• 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


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


• 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


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


• 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 MIAS-Grid, 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


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


• 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


• 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


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


• 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 best-practice document that can identify the actual threats involved with each asset in such a scenario.

Questionnaire 2: Scope and background

• Scope of Questionnaire 21. 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. Support staff2. End users3. Research staff4. Service providers5. 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

mygrid asset-based security analysis victor tan, luc moreau university of southampton mike surridge...

Documents

security analysis of

security management

aspect of security

security architecture

mygrid services

project viewpoint

project assets

innovation slide