Permalink
Fetching contributors…
Cannot retrieve contributors at this time
2908 lines (2868 sloc) 234 KB
<?xml version="1.0"?>
<!DOCTYPE cairis_model PUBLIC "-//CAIRIS//DTD MODEL 1.0//EN" "https://cairis.org/dtd/cairis_model.dtd">
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<cairis_model>
<tvtypes>
<vulnerability_type name="Design">
<description>A vulnerability inherent in the design or specification of hardware or software whereby even a perfect implementation will result in a vulnerability.</description>
</vulnerability_type>
<vulnerability_type name="Implementation">
<description>A vulnerability resulting from an error made in implementing software or hardware of a satisfactory design.</description>
</vulnerability_type>
<vulnerability_type name="Configuration">
<description>A vulnerability resulting from an error in the configuration and administration of a system or component.</description>
</vulnerability_type>
<threat_type name="Physical">
<description>Physical Security</description>
</threat_type>
<threat_type name="Natural">
<description>Environment / Acts of Nature</description>
</threat_type>
<threat_type name="Insider/Manipulation">
<description>Sometimes deliberate attempts are made to acquire information or access by manipulating staff by using a range of influencing techniques. This is sometimes described as social engineering, creating situations in which someone will willingly provide access to information, sites or systems to someone unauthorised to receive it. Customer facing personnel who have been trained to be helpful and informative can be particularly vulnerable to such attacks.</description>
</threat_type>
<threat_type name="Insider/Sabotage">
<description>Saborage is often committed by a former employee seeking revenge on their employer because of a personal grudge caused by a negative work related event such as dismissal. Although it is sometimes planned well in advance, it can also be the result of an opportunistic moment.</description>
</threat_type>
<threat_type name="Electronic/Malware">
<description>Malware is any program or file that is harmful to a computer, the term covers viruses, worms, Trojan horses, and spyware. Malware is becoming increasingly sophisticated and can be used to compromise computers to install DOS zombie programs or other malicious programs.</description>
</threat_type>
<threat_type name="Electronic/Hacking">
<description>Hackers want to get into your computer system and use them for their own purposes. There are many hacking tools available on the internet as well as online communities actively discussing hacking techniques enabling even unskilled hackers to break into unprotected systems. Hackers have a range of motives; from showing off their technical prowess, to theft of money, credentials or information, to cause damage.</description>
</threat_type>
<threat_type name="Electronic/DoS and DDoS">
<description>A Denial-of-Service (DoS) attack involves a malicious attempt to disrupt the operation of a computer system or network that is connected to the Internet. A Distributed Denial-of-Service (DDoS) attack is a more dangerous evolution of a DoS attack because it utilises a network of compromised zombie computers to mount the attack, so there is no identifiable single source.</description>
</threat_type>
<threat_type name="Electronic/Keystroke logging">
<description>Keystroke loggers work by recording the sequence of key-strokes that a user types in. The more sophisticated versions use filtering mechanisms to only record highly prized information such as email addresses, passwords and credit card number sequences.</description>
</threat_type>
<threat_type name="Electronic/Phishing and Spoofing">
<description>Phishing describes a social engineering process designed to trick an organisation\'s customers into imparting confidential information such as passwords, personal data or banking and financial details. Most commonly these are criminal attacks but the same techniques could be used by others to get sensitive information.</description>
</threat_type>
</tvtypes>
<cairis>
<project_settings name="NeuroGrid data transfer" >
<background>NeuroGrid is a project funded by the UK Medical Research Council. The project's aim is to develop a Grid-based collaborative research environment, in order to enhance collaboration both within and between clinical researchers.
The sensitivity of this clinical data and its distributed nature drives the need to find secure and effective ways of accessing and managing it.</background>
<strategic_goals>The high-level goal which needs to be satisfied is the secure processing of clinical data. This involves securely uploading clinical data to NeuroGrid, which is then analysed before aggregated results can be downloaded.</strategic_goals>
<rich_picture image="NeuroGridContext.jpg"/>
<scope>The scope of this study is restricted to the upload and download of data to and from NeuroGrid.</scope>
<naming_conventions>
<entry name="CA Certificate" >
<definition>Signs certificates. Trusted CA. Root of the chain of trust.</definition>
</entry>
<entry name="Data-set" >
<definition>A collection of NeuroGrid data.</definition>
</entry>
<entry name="Guest certificate" >
<definition>TBC</definition>
</entry>
<entry name="Honorary Contract" >
<definition>Implicit contract of trust between NHS members.</definition>
</entry>
<entry name="NHS number" >
<definition>tbc</definition>
</entry>
<entry name="User certificate" >
<definition>TBC</definition>
</entry>
</naming_conventions>
<contributors>
<contributor first_name="Shamal" surname="Faily" affiliation="OUCL" role="Scribe" />
<contributor first_name="Mark" surname="Slaymaker" affiliation="OUCL" role="Participant" />
</contributors>
</project_settings>
<environment name="Psychosis" short_code="PSY" >
<definition>The exemplar aims to integrate large existing datasets of serial MRI scans and behaviour data coupled to the NeuroGrid image analysis service into a Grid-based database, test image normalisation techniques, and develop a general ontology for a psychosis databas, for use in multi-centre studies.
The exemplar tests capabilities of NeuroGrid to deal with restrospective data, assimilate material into databases, and use of the toolkit for normalisation and analysis.</definition>
<asset_values>
<none>No impact on research</none>
<low>Increases danger of subject privacy compromise.</low>
<medium>Subject privacy may be compromised or asset compromise leads to a review of research activities.</medium>
<high>Subject privacy is compromised and/or research halted.</high>
</asset_values>
</environment>
<environment name="Stroke" short_code="STR" >
<definition>This exemplar aims to improve infrastructure for handling imaging in large studies including:
- efficient interpretation and storage of large image datasets from multicentre randomised controlled trials,
- very large studies of observer reliability to improve image interpretation,
- establishing large living archives of images linked to key metadata for diseases which require long term study to understand their true nature history and the effects of treatment, and
- for knowledge transfer.
The development of a structure for trial image metadata, based on a careful description of the metadata in the two exemplar trials is a key part of the project.</definition>
<asset_values>
<none>No impact on trials or studies.</none>
<low>Possible impact to study activities.</low>
<medium>Minor, but non-trivial, impact on trials and studies.</medium>
<high>Study activities halted.</high>
</asset_values>
</environment>
<environment name="Core Technology" short_code="TECH" >
<definition>Neurogrid Infrastructure operations.</definition>
<asset_values>
<none>No impact on NeuroGrid operations.</none>
<low>Compromise may lead to degraded service.</low>
<medium>Compromise impacts ability to intermittent or reduced access to NeuroGrid resources.</medium>
<high>Compromise leads to prolonged or permanent shut-down of NeuroGrid.</high>
</asset_values>
</environment>
</cairis>
<riskanalysis>
<role name="Data Consumer" type="Stakeholder" short_code="DCON" >
<description>Uses NeuroGrid data</description>
</role>
<role name="Data Provider" type="Stakeholder" short_code="DPRO" >
<description>Supplies data to NeuroGrid</description>
</role>
<role name="Social Engineer" type="Stakeholder" short_code="SENG" >
<description>Uses human frailty to access computational resources.</description>
</role>
<role name="Certificate Authority" type="Stakeholder" short_code="CA" >
<description>Authorises access requests for NeuroGrid and responsible for day-to-day administration.</description>
</role>
<role name="Hacker" type="Attacker" short_code="AKR" >
<description>Professional or semi-professional hacker</description>
</role>
<role name="Researcher" type="Stakeholder" short_code="RCHR" >
<description>Uses and supplies data to NeuroGrid</description>
</role>
<role name="Developer" type="Stakeholder" short_code="DEV" >
<description>Develops NeuroGrid applications based on the provided NeuroGrid API and services.</description>
</role>
<role name="Sysadmin" type="Stakeholder" short_code="SYSADMIN" >
<description>Responsible for day-to-day administration of NeuroGrid, including authorisation of access requests.</description>
</role>
<asset name="Clinical data" short_code="CD" type="Information" is_critical="0">
<description>Clinical data</description>
<significance>Unanonymised and in the wrong hands, this data can be very damaging.</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="confidentiality" value="High">
<rationale>Researchers very worried about the disclosure of partially anonymised patient data.</rationale>
</security_property>
<security_property environment="Psychosis" property="availability" value="Medium">
<rationale>Availability of NeuroGrid is quite important, but prepared to sacrifice this if doing so safeguards clinical data.</rationale>
</security_property>
<security_property environment="Stroke" property="confidentiality" value="Low">
<rationale>Clinical data is fully anonymised.</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="High">
<rationale>NeuroGrid availability important for clinical trials</rationale>
</security_property>
<security_property environment="Core Technology" property="accountability" value="High">
<rationale>Important for CA to know who is allowed to access what data items.</rationale>
</security_property>
</asset>
<asset name="User certificate" short_code="UC" type="Information" is_critical="0">
<description>User certificate</description>
<significance>Necessary to access the NeuroGrid portal.</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="confidentiality" value="Medium">
<rationale>None</rationale>
</security_property>
<security_property environment="Psychosis" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Psychosis" property="accountability" value="Low">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="confidentiality" value="Medium">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="accountability" value="Low">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="confidentiality" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="accountability" value="Low">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="Access Control Policy" short_code="AC" type="Information" is_critical="0">
<description>Access Control Policy</description>
<significance>This decides who can access what in NeuroGrid.</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="integrity" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Psychosis" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="integrity" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="integrity" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="availability" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="Analysis data" short_code="AD" type="Information" is_critical="0">
<description>Analysis data</description>
<significance>If this data has not been properly sanitised before or after analysis, then confidentiality could be endangered.</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="confidentiality" value="Medium">
<rationale>None</rationale>
</security_property>
<security_property environment="Psychosis" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="confidentiality" value="Low">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="Guest Certificate" short_code="GC" type="Information" is_critical="0">
<description>Guest Certificate</description>
<significance>Many users have not registered for NeuroGrid but have access to Guest Certificates</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="availability" value="Low">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="availability" value="Low">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="Delegation token" short_code="DT" type="Information" is_critical="0">
<description>Delegation token</description>
<significance>None known</significance>
<critical_rationale></critical_rationale>
<security_property environment="Core Technology" property="integrity" value="Medium">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="availability" value="Low">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="accountability" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="WebDAV Collection" short_code="WDC" type="Information" is_critical="0">
<description>WebDAV Collection</description>
<significance>Accessing WebDAV folders allows access to process NeuroGrid data</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="availability" value="Medium">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="Low">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="accountability" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="WebDAV Resource" short_code="WDR" type="Information" is_critical="0">
<description>WebDAV Resource</description>
<significance>WebDAV resources may be input or output to workflows</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="availability" value="Medium">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="Low">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="accountability" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="Grid meta-data" short_code="GM" type="Information" is_critical="0">
<description>Grid meta-data</description>
<significance>Meta-data used to control aspects of the NeuroGrid infrastructure.</significance>
<critical_rationale></critical_rationale>
<security_property environment="Stroke" property="confidentiality" value="Low">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="integrity" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="availability" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="Host Configuration File" short_code="HCF" type="Information" is_critical="0">
<description>Host Configuration File</description>
<significance>Defines virtual hosts and allowable modules</significance>
<critical_rationale></critical_rationale>
<security_property environment="Stroke" property="integrity" value="Medium">
<rationale>Corrupting running of web server could lead to unauthorised access to resources</rationale>
</security_property>
<security_property environment="Core Technology" property="integrity" value="Medium">
<rationale>Corrupting running of web server could lead to unauthorised access to resources</rationale>
</security_property>
</asset>
<asset name="CA Certificate" short_code="CA" type="Information" is_critical="0">
<description>CA Certificate</description>
<significance>Obtaining this allows NeuroGrid meta-data to be modified</significance>
<critical_rationale></critical_rationale>
<security_property environment="Core Technology" property="accountability" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="Personal certificate" short_code="PC" type="Information" is_critical="0">
<description>Personal certificate</description>
<significance>Allows access to analysis data</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="confidentiality" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="confidentiality" value="Low">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="confidentiality" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="Portal" short_code="P" type="Systems" is_critical="0">
<description>Portal</description>
<significance>Unavailability of the portal is synonymous with unavailability of NeuroGrid for many users.</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="availability" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="Web-browser" short_code="WB" type="Software" is_critical="0">
<description>Web-browser</description>
<significance>Most tasks performed by the user involve this asset.</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="integrity" value="Medium">
<rationale>None</rationale>
</security_property>
<security_property environment="Psychosis" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="integrity" value="Medium">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="Workflow" short_code="WF" type="Software" is_critical="0">
<description>Workflow</description>
<significance>Workflows can tie up system resources and are exposed to sensitive data when running.</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="integrity" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Psychosis" property="availability" value="Medium">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="integrity" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="Medium">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="accountability" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="Client workstation" short_code="CW" type="Hardware" is_critical="0">
<description>Client workstation</description>
<significance>Certain software and data files need to be installed on this machine to access NeuroGrid.</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="confidentiality" value="Low">
<rationale>None</rationale>
</security_property>
<security_property environment="Psychosis" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="confidentiality" value="Low">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<asset name="Data node" short_code="DN" type="Hardware" is_critical="0">
<description>Data node</description>
<significance>Obtaining physical or virtual access to these machines can compromise the data it holds.</significance>
<critical_rationale></critical_rationale>
<security_property environment="Psychosis" property="availability" value="Medium">
<rationale>None</rationale>
</security_property>
<security_property environment="Stroke" property="availability" value="High">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="availability" value="Medium">
<rationale>None</rationale>
</security_property>
<security_property environment="Core Technology" property="accountability" value="High">
<rationale>None</rationale>
</security_property>
</asset>
<vulnerability name="Partial anonymisation" type="Design">
<description>Psychosis data can be semi-trivially unanonyimised by combining it with personal meta-data such as name or date-of-birth</description>
<vulnerability_environment name="Psychosis" severity="Catastrophic">
<vulnerable_asset name="Clinical data" />
</vulnerability_environment>
</vulnerability>
<vulnerability name="Invisible College" type="Design">
<description>Clinicians will habitually trust other clinicians with confidential information.</description>
<vulnerability_environment name="Psychosis" severity="Marginal">
<vulnerable_asset name="Clinical data" />
<vulnerable_asset name="User certificate" />
<vulnerable_asset name="Analysis data" />
</vulnerability_environment>
<vulnerability_environment name="Stroke" severity="Marginal">
<vulnerable_asset name="Clinical data" />
<vulnerable_asset name="User certificate" />
<vulnerable_asset name="Analysis data" />
<vulnerable_asset name="Personal certificate" />
</vulnerability_environment>
</vulnerability>
<vulnerability name="Intermediate data accessibility" type="Design">
<description>Workflows processing clinical data have access to intermediate data which may expose unauthorised clinical data.</description>
<vulnerability_environment name="Stroke" severity="Critical">
<vulnerable_asset name="Clinical data" />
<vulnerable_asset name="Analysis data" />
</vulnerability_environment>
</vulnerability>
<vulnerability name="Replay vulnerability" type="Implementation">
<description>The same user certificate can be used over and over again if the server is compromised.</description>
<vulnerability_environment name="Core Technology" severity="Critical">
<vulnerable_asset name="User certificate" />
<vulnerable_asset name="Delegation token" />
<vulnerable_asset name="Data node" />
</vulnerability_environment>
</vulnerability>
<vulnerability name="Workflow channel" type="Implementation">
<description>Workflows implemented in most programming languages can exploit an ability to communicate to other processes or communicate to the outside world.</description>
<vulnerability_environment name="Psychosis" severity="Critical">
<vulnerable_asset name="Workflow" />
</vulnerability_environment>
<vulnerability_environment name="Stroke" severity="Marginal">
<vulnerable_asset name="Workflow" />
</vulnerability_environment>
<vulnerability_environment name="Core Technology" severity="Catastrophic">
<vulnerable_asset name="Workflow" />
</vulnerability_environment>
</vulnerability>
<vulnerability name="Certificate ubiquity" type="Configuration">
<description>Certificates can be shared, allowing unauthorised users access to the NeuroGrid portal.</description>
<vulnerability_environment name="Psychosis" severity="Critical">
<vulnerable_asset name="User certificate" />
</vulnerability_environment>
<vulnerability_environment name="Stroke" severity="Critical">
<vulnerable_asset name="User certificate" />
<vulnerable_asset name="Personal certificate" />
</vulnerability_environment>
</vulnerability>
<vulnerability name="OTS vulnerabilty" type="Configuration">
<description>If server nodes are not constantly patched, then they may fall prey to an uncovered COTS/Open Source vulnerability.</description>
<vulnerability_environment name="Core Technology" severity="Marginal">
<vulnerable_asset name="Data node" />
</vulnerability_environment>
</vulnerability>
<attacker name="Carol" image="Carol.jpg">
<description>Carol is a freelance journalist working in the South East of England. Having heard stories about data theft, she is currently investigating a number of e-Science projects, including NeuroGrid, to see if she can find a story.
As security is a topical subject in the media, Carol has been able to secure some seed money from a national newspaper to fund her investigation.</description>
<attacker_environment name="Psychosis">
<attacker_role name="Social Engineer" />
<motivation name="Headlines/press" />
<capability name="Resources/Funding" value="Low" />
<capability name="Resources/Personnel and Time" value="Medium" />
</attacker_environment>
<attacker_environment name="Stroke">
<attacker_role name="Social Engineer" />
<motivation name="Headlines/press" />
<capability name="Resources/Personnel and Time" value="Medium" />
<capability name="Resources/Funding" value="High" />
</attacker_environment>
</attacker>
<attacker name="Mallory" image="Mallory.jpg">
<description>Mallory is a bot maintainer. He is constantly on the look out for new, powerful machines to add to the bespoke Botnets he builds for his clients.</description>
<attacker_environment name="Psychosis">
<attacker_role name="Hacker" />
<motivation name="System resource theft" />
<motivation name="Network resource theft" />
<capability name="Resources/Funding" value="Low" />
<capability name="Resources/Personnel and Time" value="Medium" />
<capability name="Knowledge/Education and Training" value="Medium" />
<capability name="Knowledge/Methods" value="Medium" />
<capability name="Software" value="High" />
</attacker_environment>
<attacker_environment name="Stroke">
<attacker_role name="Hacker" />
<motivation name="System resource theft" />
<motivation name="Network resource theft" />
<capability name="Resources/Funding" value="Low" />
<capability name="Resources/Personnel and Time" value="Medium" />
<capability name="Knowledge/Education and Training" value="Medium" />
<capability name="Knowledge/Methods" value="Medium" />
<capability name="Software" value="High" />
</attacker_environment>
<attacker_environment name="Core Technology">
<attacker_role name="Hacker" />
<motivation name="System resource theft" />
<motivation name="Network resource theft" />
<capability name="Resources/Funding" value="Low" />
<capability name="Resources/Personnel and Time" value="Medium" />
<capability name="Knowledge/Education and Training" value="Medium" />
<capability name="Knowledge/Methods" value="Medium" />
<capability name="Software" value="High" />
</attacker_environment>
</attacker>
<attacker name="Trudy" image="Trudy.jpg">
<description>Trudy is a 17 year old student studying ICT at a local FE college. Although she has little formal computer security education, she likes to visit black hat web-sites and play with known exploits at attack script repositories. Her interest is not so much personal gain as it is understanding how these scripts work.</description>
<attacker_environment name="Stroke">
<attacker_role name="Hacker" />
<motivation name="Indifference" />
<capability name="Software" value="Low" />
<capability name="Knowledge/Education and Training" value="Low" />
<capability name="Resources/Personnel and Time" value="Medium" />
<capability name="Technology" value="Medium" />
<capability name="Knowledge/Books and Manuals" value="High" />
</attacker_environment>
<attacker_environment name="Core Technology">
<attacker_role name="Hacker" />
<motivation name="Thrill-seeking" />
<capability name="Software" value="Low" />
<capability name="Knowledge/Education and Training" value="Low" />
<capability name="Resources/Personnel and Time" value="Medium" />
<capability name="Technology" value="Medium" />
<capability name="Knowledge/Books and Manuals" value="High" />
</attacker_environment>
</attacker>
<attacker name="Yves" image="Yves.jpg">
<description>Yves is a high-flying post-doctoral research fellow, associated with the Stroke exemplar. He has very limited access to NeuroGrid, but has some novel theories which could drastically cut the time take to perform clinical trials. Yves can't wait for ethical approval to access the data he needs, so is looking at other ways of accessing clinical data sets on NeuroGrid.</description>
<attacker_environment name="Stroke">
<attacker_role name="Data Consumer" />
<attacker_role name="Social Engineer" />
<motivation name="Headlines/press" />
<motivation name="Data theft" />
<capability name="Resources/Personnel and Time" value="Low" />
<capability name="Software" value="Low" />
<capability name="Resources/Funding" value="Medium" />
</attacker_environment>
</attacker>
<threat name="Social engineering" type="Insider/Manipulation">
<method>Manipulate and exploit trust</method>
<threat_environment name="Psychosis" likelihood="Occasional" >
<threat_attacker name="Carol" />
<threatened_asset name="User certificate" />
<threatened_asset name="Client workstation" />
<threatened_property name="confidentiality" value="High">
<rationale>Carol wants to disclose information about project assets.</rationale>
</threatened_property>
</threat_environment>
<threat_environment name="Stroke" likelihood="Occasional" >
<threat_attacker name="Yves" />
<threatened_asset name="User certificate" />
<threatened_asset name="Personal certificate" />
<threatened_asset name="Client workstation" />
<threatened_property name="confidentiality" value="High">
<rationale>Yves wants to access unauthorised certificates for his own use.</rationale>
</threatened_property>
</threat_environment>
</threat>
<threat name="Replay attack" type="Electronic/Hacking">
<method>Replay attack</method>
<threat_environment name="Core Technology" likelihood="Occasional" >
<threat_attacker name="Mallory" />
<threatened_asset name="Data node" />
<threatened_property name="confidentiality" value="Medium">
<rationale>None</rationale>
</threatened_property>
<threatened_property name="availability" value="High">
<rationale>None</rationale>
</threatened_property>
<threatened_property name="accountability" value="High">
<rationale>None</rationale>
</threatened_property>
</threat_environment>
</threat>
<threat name="Trojan Horse" type="Electronic/Malware">
<method>Trojan Horse</method>
<threat_environment name="Psychosis" likelihood="Occasional" >
<threat_attacker name="Mallory" />
<threatened_asset name="User certificate" />
<threatened_asset name="Web-browser" />
<threatened_asset name="Client workstation" />
<threatened_property name="confidentiality" value="High">
<rationale>None</rationale>
</threatened_property>
<threatened_property name="integrity" value="High">
<rationale>None</rationale>
</threatened_property>
<threatened_property name="accountability" value="Medium">
<rationale>None</rationale>
</threatened_property>
</threat_environment>
<threat_environment name="Stroke" likelihood="Occasional" >
<threat_attacker name="Mallory" />
<threatened_asset name="User certificate" />
<threatened_asset name="Web-browser" />
<threatened_asset name="Client workstation" />
<threatened_property name="confidentiality" value="Low">
<rationale>None</rationale>
</threatened_property>
<threatened_property name="integrity" value="High">
<rationale>None</rationale>
</threatened_property>
<threatened_property name="accountability" value="Medium">
<rationale>None</rationale>
</threatened_property>
</threat_environment>
<threat_environment name="Core Technology" likelihood="Occasional" >
<threat_attacker name="Mallory" />
<threatened_asset name="User certificate" />
<threatened_asset name="Personal certificate" />
<threatened_asset name="Web-browser" />
<threatened_asset name="Client workstation" />
<threatened_property name="confidentiality" value="High">
<rationale>None</rationale>
</threatened_property>
<threatened_property name="integrity" value="High">
<rationale>None</rationale>
</threatened_property>
<threatened_property name="accountability" value="Medium">
<rationale>None</rationale>
</threatened_property>
</threat_environment>
</threat>
<threat name="DOS" type="Electronic/DoS and DDoS">
<method>DOS</method>
<threat_environment name="Core Technology" likelihood="Occasional" >
<threat_attacker name="Trudy" />
<threatened_asset name="Client workstation" />
<threatened_asset name="Data node" />
<threatened_property name="availability" value="High">
<rationale>None</rationale>
</threatened_property>
</threat_environment>
</threat>
<threat name="Meta-data modification" type="Electronic/Hacking">
<method>Meta-data modification</method>
<threat_environment name="Core Technology" likelihood="Remote" >
<threat_attacker name="Mallory" />
<threatened_asset name="Grid meta-data" />
<threatened_property name="integrity" value="High">
<rationale>None</rationale>
</threatened_property>
<threatened_property name="accountability" value="High">
<rationale>None</rationale>
</threatened_property>
</threat_environment>
</threat>
<threat name="Clinical data modification" type="Electronic/Hacking">
<method>Clinical data modification</method>
<threat_environment name="Stroke" likelihood="Improbable" >
<threat_attacker name="Yves" />
<threatened_asset name="Clinical data" />
<threatened_property name="confidentiality" value="High">
<rationale>None</rationale>
</threatened_property>
<threatened_property name="integrity" value="High">
<rationale>None</rationale>
</threatened_property>
<threatened_property name="availability" value="Medium">
<rationale>None</rationale>
</threatened_property>
<threatened_property name="accountability" value="Medium">
<rationale>None</rationale>
</threatened_property>
</threat_environment>
</threat>
<risk name="Unauthorised Certificate Access" vulnerability="Certificate ubiquity" threat="Social engineering">
<misusecase environment="Psychosis">
<narrative>Carol gained access to the Computing Laboratory by tail-gating one of the many new DTC students arriving that day. When she reached the attrium she asked a nearby porter for directions to the Neurosciences areas. Carol followed the directions and eventually reached an open-plan area with a number of PCs. The computer room is a shared work area used by the many post-docs working in the department. Carol espied an unused PC, next to which was a man in his mid-20s who appeared to be deeply engrossed in his work. Carol approached the main and attempted to get his attention. "Hi there", Carol said, "I'm Carol, and I'm a new post-doc in the group". Dave looked up from his PC and smiled. "Hi", said the over-worked post-doc, "I'm Dave. Due mentioned something about a new post-doc. Well, I see you found your way here ok.". "Eventually", said Carol, "Oxford is a bit of a tardis isn't it. Is this desk free?". "Sure, make yourself at home", replied Dave. Carol sat down and pulled an A4 pad and some dog-eared papers from the day-sac she had been carrying around; she wanted to give the impression she was annotating some academic papers.
After about 30 minutes, Dave sat back from his PC and sighed. Noticing this, and sensing an opportunity, Carol asked "Is there anywhere we can get a coffee around here?" "You must have been reading my mind", Dave said, "Taylors is pretty good, which I'm just on my way to now - do you want to come?".
On the way to the coffee shop, Carol gave her cover story to Dave. She was a new post-doc who had started today, but her new supervisor was away that week, she was told to just "get on with stuff" until he returned from leave. She was obviously a bit frustrated though, as she had no login details and couldn't download any of her supervisor's previous analysis from NeuroGrid. "No problem", said Dave, "I'll just log you in when we get back, and I'll give you a copy of my NeuroGrid certificate on a USB stick". On their return, Dave logged Carol into the guest PC and gave her the certificate as promised. For the rest of the day, Carol surfed the web until about 7pm when Dave went home. When she was sure the office was empty, Carol took out her camera and took several shots of the PC, with the login screen of the NeuroGrid portal clearly visible. She then scribbled down the events of the day on her A4 pad before leaving the building to catch the Oxford Tube back to London.</narrative>
</misusecase>
<misusecase environment="Stroke">
<narrative>Yves knew for sometime that Sally had access to a data-set he needed to finish off a trial in time for that journal submission deadline. However, due to administrative overhead of obtaining ethical approval, Yves never got around to applying for access to that data-set himself. Besides, he was so busy doing research, where was he going to get the time to drop everything to fill in the necessary paperwork. He, therefore, decide to progress his research and deal with getting the data he needed precisely when he needed it.
"Aaarrgghh" cried Yves. "What's up", asked Sally from the other end of the open-plan office they shared. "I'm missing several samples of data from that batch of images we got from the Phillipines last week", said Yves.
Sally came over and looking at the workflow results on Yves screen. "Ah", said Sally, "I think the data is there but you just don't have access to it." "What!" exclaimed Yves, "I was told I had everything I needed from Mike, why didn't he tell me I was missing images from this data set. How am I supposed to submit this paper by the end of the week without a complete validation". Yves put his head in his hands.
"You know what", said Sally, "I think I've got access to that data. Why don't you just login as me and resubmit your workflow that way".
Yves perked up; "Sally, you're a star", Yves said, "you've just earned yourself some drinks and a paper acknowledgement.".
Sally walked back to her desk, copied her digital certificate to a USB stick, before walking back to Yves to hand over the key. "Ta", said Yves, before loading the digital certificate to his web-browser, logging back into NeuroGrid, and re-submitting his workflow. </narrative>
</misusecase>
</risk>
<risk name="Replay-based resource exploit" vulnerability="Replay vulnerability" threat="Replay attack">
<misusecase environment="Core Technology">
<narrative>Several weeks ago, Mallory installed a rootkit on a PC in the UK which happened to be used to access NeuroGrid. While examining the PC recently, Mallory noticed certain characteristics of the PC suggesting that this machine was being used to access a computational grid.
After setting up a packet sniffer to monitor traffic, Mallory spotted the potential for a replay attack which could be reproduced from several different machines. Mallory subsequently wrote a script and ran it from a different machine using the same root certificate. It worked! Mallory now had a way of uploading workflows on demand to NeuroGrid - useful for any high-intensive processing needing to be carried out, such as breaking symmetric encryption.</narrative>
</misusecase>
</risk>
<risk name="User Certificate Theft" vulnerability="Certificate ubiquity" threat="Trojan Horse">
<misusecase environment="Psychosis">
<narrative>Alice was in a hurry. She desparately had to catch that 10.15 train to London but she didn't have time to go all the way back to the Comlab to download the latest analysis results - results she needed for the presentation she was giving at UCL. As she crossed Hythe Bridge, Alice remembered that there was a cheap call shop near the chinese supermarket; perhaps they had internet access. Alice hurried into the shop and noticed a bank of PCs by the far wall.
After enquiring about the use of a PC, Alice was told it would be 5 pounds for 30 minutes use. She only needed the machine for about 5 minutes but her need was urgent so she paid up and hurried over to the nearest PC. Alice reached for her USB stick, transferred her root certificate to the machine, logged into the NeuroGrid portal, downloaded her results from her WebDAV folder, before transferring them to his USB stick. After glancing nervously at her watch, she pulled out his USB, closed the web-browser down and walked briskly out of the shop and towards the station. Perhaps she might make that train after all.
Two hours later, and several hundred miles away, Mallory checked his bot herd status logs. It looks like he was the proud owner of 10 new PCs. Mallory ran the machine inventory script of his new prizes, and noticed that one of them had earlier access the NeuroGrid portal. "Yes!" Mallory exclaimed to himself as he checked the browser cache and found an elusive digital certificate. As Mallory transferred this certificate to his machine, ensuring afterwards it was removed from the newly owned PC at the internet cafe in Oxford, he could only wonder at the processing power now made available to him.</narrative>
</misusecase>
<misusecase environment="Stroke">
<narrative>Bob was in a hurry. He desparately had to catch that 10.15 train to London but he didn't have time to go all the way back to the Comlab to download the latest analysis results - results he needed for the presentation he was giving at UCL. As he crossed Hythe Bridge, Bob remembered that there was a cheap call shop near the chinese supermarket; perhaps they had internet access. Bob hurried into the shop and noticed a bank of PCs by the far wall.
After enquiring about the use of a PC, Bob was told it would be 5 pounds for 30 minutes use. He only needed the machine for about 5 minutes but his need was urgent so he paid up and hurried over to the nearest PC. Bob reached for her USB stick, transferred his root certificate to the machine, logged into the NeuroGrid portal, downloaded his results from his WebDAV folder, before transferring them to his USB stick. After glancing nervously at his watch, he pulled out his USB, closed the web-browser down and walked briskly out of the shop and towards the station. Perhaps he might make that train after all.
Two hours later, and several hundred miles away, Mallory checked his bot herd status logs. It looks like he was the proud owner of 10 new PCs. Mallory ran the machine inventory script of his new prizes, and noticed that one of them had earlier access the NeuroGrid portal. "Yes!" Mallory exclaimed to himself as he checked the browser cache and found an elusive digital certificate. As Mallory transferred this certificate to his machine, ensuring afterwards it was removed from the newly owned PC at the internet cafe in Oxford, he could only wonder at the processing power now made available to him.</narrative>
</misusecase>
</risk>
<risk name="Unanonymised clinical data" vulnerability="Partial anonymisation" threat="Social engineering">
<misusecase environment="Psychosis">
<narrative>Finds partially anonymised images on PC, scours recycle email area and discovers image part of a batch from UCL Hospital. Scours a bit further and discovers name of doctor who emailed it. Enough info to go to UCL hospital, masquerade as someone who knows that doctor and piece together more info about the patient.</narrative>
</misusecase>
</risk>
<risk name="Change clinical data using broken workflow" vulnerability="Intermediate data accessibility" threat="Clinical data modification">
<misusecase environment="Stroke">
<narrative>Yves discovers outliers in a data set he doesn't have access to, and decides to change the clinical data to remove it. Finds a way to hack some clinical data via NeuroGrid controls. This requires crashing a workflow at the point that data is exposed in order to generate clinical data.
Yves persuades Sally to run a workflow for him because he is a hurry and still doesn't have time to get ethical approval. Sally uploads workflow to NeuroGrid, which runs and changes the data.</narrative>
</misusecase>
</risk>
<response risk="Unauthorised Certificate Access" type="Prevent" >
<prevent_environment name="Psychosis" />
<prevent_environment name="Stroke" />
</response>
<response risk="Replay-based resource exploit" type="Transfer" >
<transfer_environment name="Core Technology">
<response_role name="Certificate Authority" cost="Low" />
<rationale>Administrators best placed to address this risk.</rationale>
</transfer_environment>
</response>
<asset_association environment="Psychosis" head_name="Data node" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Portal" />
<asset_association environment="Psychosis" head_name="Data node" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Access Control Policy" />
<asset_association environment="Psychosis" head_name="Web-browser" head_nav="0" head_adornment="Aggregation" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="User certificate" />
<asset_association environment="Psychosis" head_name="Web-browser" head_nav="0" head_adornment="Aggregation" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Personal certificate" />
<asset_association environment="Psychosis" head_name="Web-browser" head_nav="0" head_adornment="Aggregation" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Guest certificate" />
<asset_association environment="Stroke" head_name="Data node" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Portal" />
<asset_association environment="Stroke" head_name="Data node" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Access Control Policy" />
<asset_association environment="Stroke" head_name="Web-browser" head_nav="0" head_adornment="Aggregation" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="User certificate" />
<asset_association environment="Stroke" head_name="Web-browser" head_nav="0" head_adornment="Association" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Portal" />
<asset_association environment="Stroke" head_name="Web-browser" head_nav="0" head_adornment="Aggregation" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Personal certificate" />
<asset_association environment="Stroke" head_name="Web-browser" head_nav="0" head_adornment="Aggregation" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Guest certificate" />
<asset_association environment="Core Technology" head_name="CA Certificate" head_nav="0" head_adornment="Association" head_nry="1" head_role="controls" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Grid meta-data" />
<asset_association environment="Core Technology" head_name="Data node" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Access Control Policy" />
<asset_association environment="Core Technology" head_name="Data node" head_nav="0" head_adornment="Association" head_nry="1..a" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Grid meta-data" />
<asset_association environment="Core Technology" head_name="Data node" head_nav="0" head_adornment="Composition" head_nry="1..a" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Clinical data" />
<asset_association environment="Psychosis" head_name="Web-browser" head_nav="0" head_adornment="Association" head_nry="a" head_role="" tail_role="" tail_nry="a" tail_adornment="Association" tail_nav="0" tail_name="Portal" />
<asset_association environment="Core Technology" head_name="Data node" head_nav="0" head_adornment="Association" head_nry="a" head_role="" tail_role="" tail_nry="a" tail_adornment="Association" tail_nav="0" tail_name="Delegation token" />
<asset_association environment="Psychosis" head_name="Data node" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="Clinical data" />
<asset_association environment="Psychosis" head_name="Data node" head_nav="0" head_adornment="Aggregation" head_nry="1" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="Analysis data" />
<asset_association environment="Psychosis" head_name="Data node" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="WebDAV Collection" />
<asset_association environment="Psychosis" head_name="WebDAV Collection" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="WebDAV Resource" />
<asset_association environment="Psychosis" head_name="Data node" head_nav="0" head_adornment="Aggregation" head_nry="a" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="Workflow" />
<asset_association environment="Psychosis" head_name="Workflow" head_nav="0" head_adornment="Association" head_nry="a" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="Clinical data" />
<asset_association environment="Psychosis" head_name="Client workstation" head_nav="0" head_adornment="Composition" head_nry="1..a" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="Web-browser" />
<asset_association environment="Psychosis" head_name="Workflow" head_nav="0" head_adornment="Association" head_nry="1..a" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="Analysis data" />
<asset_association environment="Psychosis" head_name="WebDAV Resource" head_nav="0" head_adornment="Inheritance" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Analysis data" />
<asset_association environment="Stroke" head_name="Data node" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="Clinical data" />
<asset_association environment="Stroke" head_name="Data node" head_nav="0" head_adornment="Aggregation" head_nry="1" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="Analysis data" />
<asset_association environment="Stroke" head_name="Data node" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="WebDAV Collection" />
<asset_association environment="Stroke" head_name="Data node" head_nav="0" head_adornment="Aggregation" head_nry="a" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="Workflow" />
<asset_association environment="Stroke" head_name="Workflow" head_nav="0" head_adornment="Association" head_nry="a" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="Clinical data" />
<asset_association environment="Stroke" head_name="Client workstation" head_nav="0" head_adornment="Composition" head_nry="1..a" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="Web-browser" />
<asset_association environment="Stroke" head_name="Workflow" head_nav="0" head_adornment="Association" head_nry="1..a" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="Analysis data" />
<asset_association environment="Stroke" head_name="WebDAV Collection" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="WebDAV Resource" />
<asset_association environment="Stroke" head_name="WebDAV Resource" head_nav="0" head_adornment="Inheritance" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Analysis data" />
<asset_association environment="Stroke" head_name="Grid meta-data" head_nav="0" head_adornment="Inheritance" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Host Configuration File" />
<asset_association environment="Core Technology" head_name="Data node" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="WebDAV Collection" />
<asset_association environment="Core Technology" head_name="WebDAV Collection" head_nav="0" head_adornment="Composition" head_nry="1" head_role="" tail_role="" tail_nry="1..a" tail_adornment="Association" tail_nav="0" tail_name="WebDAV Resource" />
<asset_association environment="Core Technology" head_name="Grid meta-data" head_nav="0" head_adornment="Inheritance" head_nry="1" head_role="" tail_role="" tail_nry="1" tail_adornment="Association" tail_nav="0" tail_name="Host Configuration File" />
</riskanalysis>
<usability>
<persona name="Claire" type="Primary" assumption_persona="FALSE" image="Claire.jpg" >
<activities>Claire is a clinical researcher within the Psychosis exemplar. She is responsible for a group which is developing and testing processing pipelines for harmonising MRI images from different centres.
Claire authorises requests that other members of her group make for accessing NeuroGrid, and is officially responsible for making sure her colleagues aren't misusing their access. In practice, however, she delegates much of her responsibility to one of her more security-knowledgeable colleagues.</activities>
<attitudes>Claire feels that NeuroGrid has a lot to offer her research but, right now, its hard to see the benefits for the usability problems she faces.
Although Claire appreciates the importance of security and the confidentialty of her research subjects, authorising colleague requests for data access and liasing with the infrastructure team is a time consuming process which isn't helping her get any research done.
Claire is also perplexed at why security could cause simple workflows take such a long time to run, but she also remembers how long it used to take to get data before NeuroGrid so she can live with the performance issues.</attitudes>
<aptitudes>Claire and her colleagues follow a set of processes and guidelines when working with data uploaded to NeuroGrid.
Because obtaining data is an expensive business, Claire also tries to reuse data and analysis as much as possible, and as far as her ethics clearance allows.
</aptitudes>
<motivations>Besides her research, Claire's primary security concerns are centered around the datasets she maintains, and making sure her colleagues and collaborators can access the data they need. </motivations>
<skills>Nothing stipulated</skills>
<intrinsic>None</intrinsic>
<contextual>None</contextual>
<persona_environment name="Psychosis" is_direct="FALSE" >
<persona_role name="Researcher" />
<narrative>Nothing stipulated</narrative>
</persona_environment>
</persona>
<persona name="Tom" type="Primary" assumption_persona="FALSE" image="Tom.jpg" >
<activities>Tom is an applications developer within the Stroke exemplar.
Tom collaborates with a his clinical researchers colleagues as part of a number of on-going trials to support their research work. This includes anonymises images, and uploads these to NeuroGrid.</activities>
<attitudes>Tom is aware that some of his users find security painful, and he believes that a usable system will eventually lead to a secure system as well. Having fielding questions from his users about NeuroGrid, Tom has found that when users understand why things are the way they are, NeuroGrid makes a bit more sense.
Tom is, however, aware that medical researchers sometimes have their rules about what should and shouldn't be secured which can be source of annoyance to him.</attitudes>
<aptitudes>Nothing stipulated</aptitudes>
<motivations>Tom feels responsible for making sure that users can't do anything damaging - either to their research or system security in general.
Tom also wants security to be practical. Tom shares the infrastructure team's view on the importance of network security, and believes that, if left up to his users alone, that nothing will ever be agreed. Consequently, Tom is happy to work with whatever security controls are mandated.</motivations>
<skills>Nothing stipulated.</skills>
<intrinsic>None</intrinsic>
<contextual>None</contextual>
<persona_environment name="Stroke" is_direct="FALSE" >
<persona_role name="Developer" />
<narrative>Nothing stipulated</narrative>
</persona_environment>
</persona>
<persona name="Matt" type="Primary" assumption_persona="FALSE" image="Matt.jpg" >
<activities>Matt is a system administrator on the infrastructure team. In addition to maintaining the infrastructure, Matt and his team are responsible for securing the NeuroGrid infrastructure; this includes network security and software security on the NeuroGrid node machines.
Matt is also the designated NeuroGrid Certificate Authority and, as such, is often the first line for users in all exemplars if there are NeuroGrid access problems. As the infrastructure team are also responsible for maintaining the NeuroGrid access control policies, Matt also helps data owners craft the fine grained policies controlling access to managed datasets.</activities>
<attitudes>TBC</attitudes>
<aptitudes>TBC</aptitudes>
<motivations>TBC</motivations>
<skills>TBC</skills>
<intrinsic>None</intrinsic>
<contextual>None</contextual>
<persona_environment name="Core Technology" is_direct="FALSE" >
<persona_role name="Sysadmin" />
<narrative>Nothing stipulated.</narrative>
</persona_environment>
</persona>
<external_document name="Access control policy GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Anonymisation standards GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Application control GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Application developer GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Asset responsibility GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>None</description>
</external_document>
<external_document name="Asset sensitivity GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Certificate GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Collaborative design GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Conceptual design GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Context GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Control guarantee GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Control guidance GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Control legacy GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Control moderation GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Control sensitivity GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Control trust GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Control usability GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Cultural context GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Data consumer GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Data policy GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Data provider GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Delegated control responsibility GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Delegated responsibility GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Delivery speed GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Deployment dynamics GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Designed control GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Developer documentation GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Developer perception GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Discipline bias GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Emergent consequences GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="End-user GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="End-user perception GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Engagement artifact GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Environmental perception GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Ethical approval GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Ethical consent GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Guest certificate GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Hybrid user GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Informal trust GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Informed experience GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Infrastructure developer GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Institutional procedures GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Institutional responsibility GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Intangible factors GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Latent failures GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Legal responsibility GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Management perception GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Manual technical control GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Moral perception GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Moral responsibility GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="MRC guidelines GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Multiple controls GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Operational context GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Operational peer perception GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Organisational perception GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Password GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Procedural control GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Regulatory requirements GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Requirements perception GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Responsibility GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Role perception GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Security context GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Security culture GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Security diffusion GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Security education GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Security emphasis GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Security erosion GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Security knowledge GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Security perception GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Security role GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Security-usability balance GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Social-network support GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Socialisation GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Socio-technical measure GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Sub-cultural design activity GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Sub-cultural design artifacts GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Sub-culture norms GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Sub-culture perception GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Sub-culture values GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Sub-cultures GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Tangible factors GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Technical control GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Technical control responsibility GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Technical environment GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
<description></description>
</external_document>
<external_document name="Ticketing system GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Usability prerequisites GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="Usability sensitivity GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="User certificate GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="User expectations GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<external_document name="User proxy GT concept" version="1" date="August 2010" authors="Shamal Faily" >
<description>GT concept</description>
</external_document>
<document_reference name="Technical people develop enduser applications." contributor="SF" document="Application developer GT concept" >
<excerpt>technical people developing enduser application</excerpt>
</document_reference>
<document_reference name="Application developers make things easy for users." contributor="SF" document="Application developer GT concept" >
<excerpt>and the application developer has made it easy for him</excerpt>
</document_reference>
<document_reference name="Application developers are a liason between the exemplars and the central technical group." contributor="SF" document="Application developer GT concept" >
<excerpt>We\\\'re different from being a software end-user in that NeuroGrid provides an API so my personal role is a programmer against the API, as well essentially being a liaison for our exemplar to the Oxford group.</excerpt>
</document_reference>
<document_reference name="Many data owners do not care about security." contributor="SF" document="Asset responsibility GT concept" >
<excerpt>The third thing I\\\'ve come to realise is that actually a lot of people who own their own data, don\\\'t care about security. \\n In NeuroGrid, there is a means of tying individuals down and we can say \\\"X can only see this data\\\". \\n In NeuroGrid, we have dementia patients, stroke patients and patients with psychosis, so they are all quite vulnerable, so worrying about who can see what is quite important from our point of view.</excerpt>
</document_reference>
<document_reference name="User responsibility to not put upload unwanted data." contributor="SF" document="Asset responsibility GT concept" >
<excerpt>It is our responsibility not to put data we do not want into NeuroGrid if we do not want it to be there.</excerpt>
</document_reference>
<document_reference name="Users responsible for anonymisation." contributor="SF" document="Asset responsibility GT concept" >
<excerpt>I supposed if it\\\'s the DICOM images then it\\\'s me. \\n It\\\'s my responsibility for anonymising them as a first stage.</excerpt>
</document_reference>
<document_reference name="Asset security an exemplar responsibility." contributor="SF" document="Asset responsibility GT concept" >
<excerpt>In terms of keeping their assets secure, that is the individual exemplars. \\n They have to define the policies for their data.</excerpt>
</document_reference>
<document_reference name="Everyone should know that patient data is sensitive." contributor="SF" document="Asset sensitivity GT concept" >
<excerpt>If the people are within the NeuroGrid project, then they know this as this concept is known by everyone in the community. \\nI don\\\'t know if they follow this rule, but everyone knows that patient data is sensitive.</excerpt>
</document_reference>
<document_reference name="Disclosure of medical data causes an outcry." contributor="SF" document="Asset sensitivity GT concept" >
<excerpt>When you are working with medical data, if you have a security issue with medical data and it gets to the press, it can cause some major problems. \\nJust from looking at historical cases, where members of the public have found things out they didn\\\'t like about themselves, their friends or their family, or even in just the way the data was used, or just the fact that somebody got access to the data. \\nIt wouldn\\\'t even matter if they could do anything with the data, the fact that it can happen can cause the media to have an outcry, as this can sell papers. \\nThat sort of thing can shut down projects fairly rapidly. </excerpt>
</document_reference>
<document_reference name="Data access locked down if security concerns." contributor="SF" document="Asset sensitivity GT concept" >
<excerpt>They obviously wanted their data to be secure and it was fairly high up in the list of priorities of people I spoke to. \\nThis was particularly the case for psychosis, but that was understandable given that a lot of their patients had criminal records and other likely secondary problems. \\nThere was a police involvement usually in their cases and there is a delicate area for funding. \\nThey said at one point that if there was any problem with security, we could be quite sure that we wouldn\\\'t get access. \\nEspecially as the legislation at the time involved sectioning of schizophrenics and things like this. \\nThis was a serious concern for them. </excerpt>
</document_reference>
<document_reference name="Patient data should not get into NeuroGrid" contributor="SF" document="Asset sensitivity GT concept" >
<excerpt>For us, being involved in clinical trials, the principle concern is simply that no patient data gets out. \\nBy getting out, this means into NeuroGrid. \\nA lot of what we have to do to protect patient data has nothing to do with NeuroGrid per se, it\\\'s all things we have to do up-front before it ever goes out.</excerpt>
</document_reference>
<document_reference name="Group is motivated without the profit and law suit motive." contributor="SF" document="Asset sensitivity GT concept" >
<excerpt>Yes, we have to be motivated without the profit motive and the law suit motive I suppose. \\nThe whole group that manages clinical trials here, these are all things they are conscious of.</excerpt>
</document_reference>
<document_reference name="Clinical trial security issues affect NeuroGrid." contributor="SF" document="Asset sensitivity GT concept" >
<excerpt>You have all the normal security issues that you face with any clinical trial, such as dealing with health records. </excerpt>
</document_reference>
<document_reference name="NeuroGrid data needs to be anonymised but still useful." contributor="SF" document="Asset sensitivity GT concept" >
<excerpt>The data that is available in NeuroGrid needs to be anonymised as best you can. \\nYou need to have a certain amount of information, otherwise the information would be useless if you don\\\'t know who has got Alzheimer\\\'s disease and who is a healthy control. </excerpt>
</document_reference>
<document_reference name="Changing data leads to dangerous results" contributor="SF" document="Asset sensitivity GT concept" >
<excerpt>For local trials, when you publish data which contributes to scientific knowledge, if the data has been changed in some way then you get results which may be dangerous.</excerpt>
</document_reference>
<document_reference name="Software and data needs to be secure" contributor="SF" document="Asset sensitivity GT concept" >
<excerpt>What wasn\\\'t really raised was the need to keep the software secure either. \\nWhen you talk about assets, people tend to just think about data. </excerpt>
</document_reference>
<document_reference name="Middleware security is taken seriously" contributor="SF" document="Control sensitivity GT concept" >
<excerpt>in terms of our middleware - data transport, facilitating secure access, managing user credentials and that kind of stuff, we take this really seriously. \\nThis has been the one great driver for us as a lot of grid middleware started out as being about computational grids, and managing workflows and jobs for physicists. \\nIn e-DiaMoND, we came to the conclusion that the middleware wasn\\\'t fit for purpose and our focus has always been data and about data. \\nThat is why we abandoned GT3 and did our own thing, as we have very clear requirements with respect to security and interoperability and all these other things. </excerpt>
</document_reference>
<document_reference name="Security designed in line with functionality" contributor="SF" document="Control sensitivity GT concept" >
<excerpt> It was designed literally from the first as it was all web service base. \\nBecause of this, literally from the first web service that was written, security was put in. \\nWe worried about how to make it secure first and we built the system second.\\nSF: How was security put in in that sense?\\nI4: That was using user certificate and encryption to sign all the messages.</excerpt>
</document_reference>
<document_reference name="Certificate based security hard to change." contributor="SF" document="Control sensitivity GT concept" >
<excerpt>Because everything was designed based on certificate based security, there was no way they could actually change it unless there was another project following this project, as it could not be done within this time frame.</excerpt>
</document_reference>
<document_reference name="Technology and institutions constrain data transfers between universities." contributor="SF" document="Control sensitivity GT concept" >
<excerpt>One of the problems with universities is trying to transfer data between universities can be pretty difficult. \\nSo, you\\\'ve got large amount of information, scans which take up gigabytes of information, and you have to try and transfer that. \\nYou\\\'ve got the restrictions of what may or may not be suitable and then you\\\'ve got, in terms of technical limitations, how you can transfer data. \\nYou then need to come up with methods that are secure, so if the data fell into someone else\\\'s hands then it wouldn\\\'t be useful for them.</excerpt>
</document_reference>
<document_reference name="Data should be moved around only by those with access to it." contributor="SF" document="Control sensitivity GT concept" >
<excerpt>If you are moving data around, that can only be done by people who should be doing that and the data is accessible by people who we are happy to access the data, and the data is not modifiable in a way that you can either maliciously modify the data or accidentally, which impacts on the usability of the data. </excerpt>
</document_reference>
<document_reference name="People think of data rather than software security." contributor="SF" document="Control sensitivity GT concept" >
<excerpt>What wasn\\\'t really raised was the need to keep the software secure either. \\nWhen you talk about assets, people tend to just think about data. </excerpt>
</document_reference>
<document_reference name="Infrastructure components are separated by associative." contributor="SF" document="Control sensitivity GT concept" >
<excerpt>The infrastructure, which has two main components ; these are separated but they talk to either other. </excerpt>
</document_reference>
<document_reference name="Data owners question controls" contributor="SF" document="Control usability GT concept" >
<excerpt>Often Data Owners will say things like: Why do I need this certificate?, these certificates just get in the way and complicate the process, and I don\\\'t like these certificates.</excerpt>
</document_reference>
<document_reference name="Expressive approach for access control important" contributor="SF" document="Control usability GT concept" >
<excerpt>It was very important to us to have a more expressive and more flexible approach to who can see what.</excerpt>
</document_reference>
<document_reference name="Error messages need explanation" contributor="SF" document="Control usability GT concept" >
<excerpt>When you get an error message, you want that error message explained. When I first used the network I didnt know whether I was doing something wrong,or if the system was not working yet. Without any feedback there was nothing I could do.</excerpt>
</document_reference>
<document_reference name="Context for control is not always clear." contributor="SF" document="Control usability GT concept" >
<excerpt>When you are asked for a password, you need to know which password is being asked for. When you have more than one password and a certificate, you begin to wonder whether they are asking for the certificate or do they ask for the password ; what is it they want to know? </excerpt>
</document_reference>
<document_reference name="Important to know if error is user or system" contributor="SF" document="Control usability GT concept" >
<excerpt>If they do, then it is important to let me know. \\nThe worse thing is when you try something out and it doesn\\\'t work, you ask yourself: did I do something wrong or is the system not working?\\nIn the beginning, it was an issue that lots of things didn\\\'t work, as the system was still in the process of being built up, so it couldn\\\'t work straight away.</excerpt>
</document_reference>
<document_reference name="Support team provide error feedback." contributor="SF" document="Control usability GT concept" >
<excerpt>When you get an error message, you want that error message explained. \\nWhen I first used the network I didn\\\'t know whether I was doing something wrong, or if the system was not working yet. \\nWithout any feedback there was nothing I could do. \\nThis is why I said earlier that the easiest solution was to try things out and then go on the phone and ask [A] to get feedback straight away. \\nFor example, the data in Oxford is used in a compressed form, i.e. nii.gz format. \\nWhen I uploaded my data and it didn\\\'t work, I was told that I must use an uncompressed version. \\nWithout asking anyone, how was I supposed to know this?</excerpt>
</document_reference>
<document_reference name="Policies are too complicated for users to write." contributor="SF" document="Control usability GT concept" >
<excerpt>There are the access control policies, which say what they can and can\\\'t see. \\nWe write those, or more precisely I write those, as they are too complicated for the users to write. </excerpt>
</document_reference>
<document_reference name="Truststores are complicated and often the source of problems." contributor="SF" document="Control usability GT concept" >
<excerpt>The complication for security would be the truststores. \\nThese Java truststores (or keystores) are strange beasts. \\nThat is what we use in the server to decide whether we like a certificate or not. \\nWe see if it is trusted by the truststore. \\nThe users also have truststores to talk to. \\nIf it\\\'s going to go wrong, that is usually where the problems are.</excerpt>
</document_reference>
<document_reference name="Users appreciate getting data without waiting weeks." contributor="SF" document="Control usability GT concept" >
<excerpt>They know that if they want this data from any other sources, it takes days and days. \\nFor example, someone within another project asked us to send them some anonymised data they could find within the NeuroGrid project if they had access to. \\nAt the time they didn\\\'t have that access, so it took weeks and weeks to get the data on a DVD, encode it, post it to them, when it arrived, they had to call us for the password, so they know that having access to this kind of data is a big issue. \\nThey appreciate it even if it takes an hour to get the data, but as a general rule if it takes more than one minute for a query, then something is wrong.</excerpt>
</document_reference>
<document_reference name="Users unaccustomed to installing certificates." contributor="SF" document="Control usability GT concept" >
<excerpt>The problem is that people are not accustomed to installing certificates inside their browser. \\nUsually, we see some people who are very eager to use the portal and after a while, when you ask them \\\"what happened, I don\\\'t see you using the portal\\\", as you can\\\'t see their usage from the log files, they say \\\"well, I tried it but it didn\\\'t allow me to access it\\\". \\nSome people who go to the support page and see the screenshots explaining things step-by-step, showing how you have to download a file, upload it into your browser, etc - it seems a bit unfamiliar to people. </excerpt>
</document_reference>
<document_reference name="Users surprised at how easy certificate installation turns out to be." contributor="SF" document="Control usability GT concept" >
<excerpt>It is unfamiliar territory to install a certificate. \\nWhen they manage to do this, they say - well that was quite easily actually - , then it\\\'s done.</excerpt>
</document_reference>
<document_reference name="Usernames and passwords more familiar to users than certificates." contributor="SF" document="Control usability GT concept" >
<excerpt>At the beginning, we were thinking that as an API user, username and password is much more common so maybe it would have been more automated if the people could use username and password on the portal and, based on that username and password, when we could recognise them, we could use a certificate for them internally. </excerpt>
</document_reference>
<document_reference name="Certificates are frightening users away from the portal." contributor="SF" document="Control usability GT concept" >
<excerpt>We could have a bank of certificates automatically generated for every user and we could do this behind the scene so every transaction over the net is still secured, but users are not hassled by the certificate. \\nMaybe \\\"hassled\\\" isn\\\'t the right word, but that actually is frightening many users from using the portal. \\nWhen we explain the benefits of using certificates and when they install it, it is easy for them to use it. </excerpt>
</document_reference>
<document_reference name="Users keep non temporary data in temp folders." contributor="SF" document="Control usability GT concept" >
<excerpt>When we came to usability, we recognised that people who use the system tend to keep the files as on the temp folder more than 24 hours. \\nThey download files, they put them on the temp folder, they use them as an input to workflows and keep the output from the workflows there. \\nThey tend to use it as one of their folders. </excerpt>
</document_reference>
<document_reference name="Certificates are a mental barrier to users." contributor="SF" document="Control usability GT concept" >
<excerpt>To them, it always seemed to them really easy to install the certificate, as \\\"it\\\'s easy - just install the certificate and you\\\'re there\\\". \\nThe mental barrier to end-users, so instead of coming here and typing in a username and password.... Even a username and password is ... </excerpt>
</document_reference>
<document_reference name="Control is usable and secure." contributor="SF" document="Control usability GT concept" >
<excerpt>From what I have used, it does everything I want it to do and it doesn\\\'t do anything I don\\\'t want it to do, i.e. give my data to the wrong people. </excerpt>
</document_reference>
<document_reference name="Certificate issues have been browser issues." contributor="SF" document="Control usability GT concept" >
<excerpt>From the point of view of access, I have had problems, but the only problems have been getting certificates to work on occasion, but these have been browser issues.</excerpt>
</document_reference>
<document_reference name="Clinician perception that security is too strict." contributor="SF" document="Control usability GT concept" >
<excerpt>The biggest problem on NeuroGrid testing the portal was that it was security was too strict. \\nPeople didn\\\'t access it. \\nClinicians weren\\\'t going to download a certificate and email for a password. \\nSo, they didn\\\'t access the portal, so the requirements came quite late for that.</excerpt>
</document_reference>
<document_reference name="Clinician perception that security took too much time." contributor="SF" document="Control usability GT concept" >
<excerpt>To have clinicians, whose input was very important, they weren\\\'t wildly keen on spending time working out how to download a certificate and put it into their browsers, then email for a password and then get that. </excerpt>
</document_reference>
<document_reference name="A desire for a twospeed API" contributor="SF" document="Control usability GT concept" >
<excerpt>In our case, the ideal system would be two-speed. \\nIf you wanted the confidential data, then that would be available. \\nIf you didn\\\'t need it, it would be good to have an API which didn\\\'t require it because, as a developer, it is harder to work with. </excerpt>
</document_reference>
<document_reference name="Compared to lots of passwords" contributor="SF" document="Control usability GT concept" >
<excerpt>For a clinician who has a zillion passwords and certificates for other purposes, to have a certificate that has to be managed by NeuroGrid itself and propagated then I think that is at least a small barrier.</excerpt>
</document_reference>
<document_reference name="Certificates are not always easy to use." contributor="SF" document="Control usability GT concept" >
<excerpt>The security side can get in the way as you need to have a certificate, which hasn\\\'t always been easy to use. </excerpt>
</document_reference>
<document_reference name="Certificate problems get in the way of portal access." contributor="SF" document="Control usability GT concept" >
<excerpt>At times I haven\\\'t been able to logon to the portal as the certificates have expired or there has been some problem with the computer, or it just isn\\\'t recognising me. \\nThere are definitely some usability factors there.</excerpt>
</document_reference>
<document_reference name="Developers may potentially publish confidential information." contributor="SF" document="Delegated control responsibility GT concept" >
<excerpt>The real reason that would be useful is that it would extend the ability of the NeuroGrid system to be used by other programming languages and other web services frameworks.\\nIt doesn\\\'t have any ramifications re: security per se. \\nIn fact, you could argue that a two-speed setup like that might open the way for someone in my position, who wasn\\\'t paying attention to what he was doing, to potentially publish confidential information on the wire. </excerpt>
</document_reference>
<document_reference name="API hides details from users." contributor="SF" document="Delegated control responsibility GT concept" >
<excerpt>As there is a full API to the system, you can write your own thing and hide all of that from end users. \\nThis was our initial idea.</excerpt>
</document_reference>
<document_reference name="NeuroGrid was needed long before it was usable." contributor="SF" document="Delivery speed GT concept" >
<excerpt>One of the big problems I\\\'ve had with NeuroGrid is that I needed to use it 2 years ago but it has only been in the past few months that it has come to the stage where it is getting very usable. </excerpt>
</document_reference>
<document_reference name="Security can affect result times" contributor="SF" document="Emergent consequences GT concept" >
<excerpt>We have problems with times and sometimes security is so high it takes much longer than a user expects to get results back</excerpt>
</document_reference>
<document_reference name="Logging and certificates slows result times." contributor="SF" document="Emergent consequences GT concept" >
<excerpt>They are working on it to make it faster. \\nOne of the probable causes is the logging of everything and everywhere. \\nInternally, I suspect that certificates are tested for each step. </excerpt>
</document_reference>
<document_reference name="More emphasis on security than usability" contributor="SF" document="Emergent consequences GT concept" >
<excerpt>I think the emphasis was on making it secure, with less emphasis on the realisation that that means it would be difficult to access for certain people. \\nIt certainly is an issue for other health grids. \\nI\\\'ve got 6 of them together for a workshop. \\nGetting them to use it is a big issue, now people are saying: how sustainable is it?, how many people are actually using it?.</excerpt>
</document_reference>
<document_reference name="Technical terms confuse users." contributor="SF" document="Engagement artifact GT concept" >
<excerpt>In the beginning, we had a problem with the web folder, which was called WebDAV folder ; what is meant by _WebDAV_ folder? \\nWhen you explain that it is just a directory on the web, they go ah. \\nIt\\\'s just a name, but if you aren\\\'t an expert, you don\\\'t know if it is a technical term which means something you need to know about or not.</excerpt>
</document_reference>
<document_reference name="Portal is a frame of reference" contributor="SF" document="Engagement artifact GT concept" >
<excerpt>It isn\\\'t until you get the actual basic portal... I like what [E] said, in that you\\\'ve got to give them something to hate - something real and tangible, a vehicle for engagement. As soon as you have something, people won\\\'t say what they did want. \\nThey will automatically say what they didn\\\'t want like you can\\\'t have this and you shouldn\\\'t have the other. \\nThe requirements then became very obvious and there was a common frame of reference. \\nHaving an early form of portal as a vehicle was terrifically useful. </excerpt>
</document_reference>
<document_reference name="Metaphors helped people express ideas." contributor="SF" document="Engagement artifact GT concept" >
<excerpt>There were lots of issues where people couldn\\\'t express it before as they didn\\\'t know what things were called. \\nFor example, the WebDAV folder kept cropping up and confusing people, so when they saw the prototype they said: Oh that! That\\\'s just an ordinary folder. \\nThe security discussions came up because people couldn\\\'t access it really. \\nIn a sense, the security was too good.</excerpt>
</document_reference>
<document_reference name="Sometimes a perception that internet is safe when it is not" contributor="SF" document="Environmental perception GT concept" >
<excerpt>SF: So, there aren\\\'t any restrictions set when you install certificates via the browser? \\nIs there any guidance which says that you can\\\'t use this system in an internet cafe, or is it safe to say you wouldn\\\'t want to do it, but there is nothing in the rules you have which says that you can\\\'t?\\nI2: I\\\'m not entirely sure, but I don\\\'t think it says anywhere. \\nThis needs to be pointed out. \\nIt is difficult from a technical point of view, as the internet itself is safe and when I, with my own laptop, go to an insecure web-page, then I still have access as it all goes via my laptop. </excerpt>
</document_reference>
<document_reference name="FLOSS versions checked to ensure system remains secure." contributor="SF" document="Environmental perception GT concept" >
<excerpt>That certificate is used by some software. \\nIf there is a bug in security, this will be of concern. \\nWe need to use the most update version of, for example, web services. \\nIf you are connecting to my service which is using Apache Tomcat. \\nIf Apache Tomcat has a bug, then obviously we have a problem. \\nEvery week, I am checking to make sure I am using the latest version. \\nOn the security side at Oxford, I\\\'m sure they are doing the same thing.</excerpt>
</document_reference>
<document_reference name="Time gets in the way of data harmonisation" contributor="SF" document="Environmental perception GT concept" >
<excerpt>It is the hidden time requirements that can come and bite you, especially when it comes to installing operating systems and then installing Matlab and compilers, find the bugs, test it, try and work out what is going wrong. \\nNone of that is helping you get any data harmonisation done. </excerpt>
</document_reference>
<document_reference name="Machines storing confidential data need to be locked down." contributor="SF" document="Environmental perception GT concept" >
<excerpt>If any of NeuroGrid\\\'s nodes stored confidential information, then you get into the same set of issues any financial house or anyplace else has. \\nYou have the physical security of the servers. \\nThere is one here our images are stored on that can be accessed by NeuroGrid from any points on the grid. \\nThe others are doing the same. \\nIn our case, we would never have confidential information on that machine. \\nThe machine itself would have to be protected if it were. \\nPhysical security - how good is your firewall and all the other things you have to think about when locking down the machine. \\nAll the peculiarities of the software that you happen to use. </excerpt>
</document_reference>
<document_reference name="Concern that some foreign patient data is not kept securely." contributor="SF" document="Environmental perception GT concept" >
<excerpt>A raised this as a concern with [F] and said I\\\'m really alarmed that you don\\\'t have this data on a machine which is kept secure, surely you are covered by the ethics and the law for this and [F] said this is from the Far East. \\nI said it doesn\\\'t matter, why is this at home and why is this not on a machine. </excerpt>
</document_reference>
<document_reference name="Ideal to identify potential users from the entire project." contributor="SF" document="End-user GT concept" >
<excerpt>it would be easier to see the entire project and know how many potential users you have</excerpt>
</document_reference>
<document_reference name="A hope that users will create policies themselves in the future." contributor="SF" document="End-user GT concept" >
<excerpt>hopefully in the future perhaps the users can create those policies themselves</excerpt>
</document_reference>
<document_reference name="All users have their own certificates" contributor="SF" document="End-user GT concept" >
<excerpt>At the very top level, all the users have their own certificates</excerpt>
</document_reference>
<document_reference name="Data owners are users as well" contributor="SF" document="End-user GT concept" >
<excerpt>Yes, by the data owners effectively, who also overlap by being the users as well</excerpt>
</document_reference>
<document_reference name="Architecture leveraged experience from past projects." contributor="SF" document="Informed experience GT concept" >
<excerpt>The design leveraged experience from YYY</excerpt>
</document_reference>
<document_reference name="Reliance on infrastructure teams past experience" contributor="SF" document="Informed experience GT concept" >
<excerpt>They have built it on previous models and extended previous models that have worked, so we are reliant on them and their expertise for implementing secure and stable software on the server by using their certificates.</excerpt>
</document_reference>
<document_reference name="Researchers involved on grants were technical" contributor="SF" document="Informed experience GT concept" >
<excerpt>On NeuroGrid, we asked very similar questions but the differences we had in responses were because the people we were dealing with, the researchers involved on the grants, were very technical. </excerpt>
</document_reference>
<document_reference name="Databases fall within site research government frameworks." contributor="SF" document="Institutional procedures GT concept" >
<excerpt>All of the sites would have a database in place, which would fall within the local clinical research governance frameworks for those sites. The main thing has been collecting data and transferring data from site to site. </excerpt>
</document_reference>
<document_reference name="Unit specific operating procedures describes patient data handling" contributor="SF" document="Institutional procedures GT concept" >
<excerpt>This is an SOP document for handling patient data within the trials unit. \\nThis organisation, [B], there are any number of trials which have nothing to do with NeuroGrid/the stroke exemplar, that are going on. \\nSo, there is an SOP for handling patient data. \\nIt touches on a lot of areas which are irrelevant for NeuroGrid, as we are focusing purely on the imaging data. \\nThere is a much larger set of data on the patients themselves, the hospitals they were treated at, the treatment they got, basic demographics, outcomes. \\nAll these things are kept completely separately in separate databases out of our control. \\nMostly the SOPs are oriented around that. </excerpt>
</document_reference>
<document_reference name="Local technical support provide security guidelines." contributor="SF" document="Institutional procedures GT concept" >
<excerpt>Information Services, in a general form, have a dedicated team called Systems and Security. \\nThey issue guidelines for good computing practice. \\nThey detail what general staff should do.</excerpt>
</document_reference>
<document_reference name="Users know where their operating procedures are" contributor="SF" document="Institutional procedures GT concept" >
<excerpt>There is an SOP which deals with that. \\nI haven\\\'t read the SOP, but I know that there is, for everyone in this department, there is an SOP, which says what we should do if someone is not available.</excerpt>
</document_reference>
<document_reference name="Line manager responsible for user behaviour." contributor="SF" document="Institutional responsibility GT concept" >
<excerpt>[A] may see that because as myself and I3 are employees, that would be his problem to deal with</excerpt>
</document_reference>
<document_reference name="Managers do not deal with security" contributor="SF" document="Institutional responsibility GT concept" >
<excerpt>To be honest, I don\\\'t think they deal with the security aspect. \\nFor example, my supervisor here is very keen to test the portal and he has a certificate install and is using a master password, so there is no concern if someone else is using his computer or laptop as they will have their password anyway. </excerpt>
</document_reference>
<document_reference name="Institutions have some responsibility for server security." contributor="SF" document="Institutional responsibility GT concept" >
<excerpt>There is a small amount of responsibility with the institutions participating because NeuroGrid is secured over a set of nodes, just a set of servers, in different physical locations. \\nWe have one here. \\nSo, there is some small responsibility we have. \\nThe servers themselves are configured and managed centrally, that\\\'s why 95% of responsibility lies at Oxford. \\nThe responsibility locally is don\\\'t mess that up. </excerpt>
</document_reference>
<document_reference name="IS department handed server responsibility to infrastructure team." contributor="SF" document="Institutional responsibility GT concept" >
<excerpt>If you think about the server itself, the server is physically housed in our Information Services (IS) department. \\nThey have been responsible for housing it in their secure computer room. \\nThey initially took receipt of the server when it came, did some initial set-up and then informed Oxford when it was at the initial stage</excerpt>
</document_reference>
<document_reference name="Users sign an institutional code of practice." contributor="SF" document="Institutional responsibility GT concept" >
<excerpt>The security after that, in terms of what I\\\'ve just described, I would expect Information Services to be responsible. \\nThat is housing the server, doing its backups, doing disaster recovery if anything went wrong. \\nThe backups are stored off-site but we just leave all that...\\nThey also, all users, are responsible for signing a code of practice. \\nThis is basically computer use or computer misuse. \\nYou are sacked if you are a member of staff and have abused the network. \\nStudents can be asked to leave effectively if they have hacked the network. \\nWe just leave everything like that to them [IS]. </excerpt>
</document_reference>
<document_reference name="Some managerial responsibility for data delegated." contributor="SF" document="Institutional responsibility GT concept" >
<excerpt>I think [B] is ultimately responsible for security. \\nSome of that responsibility is designated to others on a day-to-day basis, but ultimately he assumes the complete responsibility for that.</excerpt>
</document_reference>
<document_reference name="Managers responsible for own data." contributor="SF" document="Institutional responsibility GT concept" >
<excerpt>\\\"He would have responsibility for all the XXX data. \\\"</excerpt>
</document_reference>
<document_reference name="Exemplar PI assumes overall responsibility" contributor="SF" document="Institutional responsibility GT concept" >
<excerpt>I guess that as PI of the exemplar as a whole, he would assume the responsibility even though there would be someone with responsibility for that site as well. </excerpt>
</document_reference>
<document_reference name="Uploaders legally obliged to ensure data does not fall into wrong hands." contributor="SF" document="Legal responsibility GT concept" >
<excerpt>So, once you are on the grid, the main thing is that, because it\\\'s medical data, you are obliged to make sure it doesn\\\'t fall into anyone else\\\'s hands.\\nSF: When you say \\\'you\\\'re obliged to make sure the data doesn\\\'t fall into people\\\'s hands\\\', how are those obligations made explicit.\\nI7: They are given to us. \\nThere is the data protection act, which is the obvious thing. </excerpt>
</document_reference>
<document_reference name="Medics get broad sweep of who can access data." contributor="SF" document="Moral perception GT concept" >
<excerpt>So, medics making ethical approvals tend to get a fairly broad sweep of who can access the data ; they get quite a lot of latitude on who they allow to access the data. \\nIf you are a researcher from other areas, you tend to get a very tight control on who can and can\\\'t access the data. </excerpt>
</document_reference>
<document_reference name="Principles and ethics committee responsible for approval." contributor="SF" document="Moral responsibility GT concept" >
<excerpt>A lot of it is down to ethics committees. \\nThere are the Caldicott Guardian principles as well.</excerpt>
</document_reference>
<document_reference name="Ethics ensure user does not allow data to leave server." contributor="SF" document="Moral responsibility GT concept" >
<excerpt>That is bad information to get out into the field because of insurance issues or because people won\\\'t employ them. \\nSo, his ethics are very strict to the extent that he never wanted his data to leave the server. He would only allow processed results to leave. </excerpt>
</document_reference>
<document_reference name="Users agree not to misuse data." contributor="SF" document="Moral responsibility GT concept" >
<excerpt>For the data nodes, if you are a NeuroGrid person, when you get your certificate, you agree not to misuse the data. \\nIf you query the data, you technically not use the data other than what you agree to.</excerpt>
</document_reference>
<document_reference name="Everyone responsible for security" contributor="SF" document="Moral responsibility GT concept" >
<excerpt>SF: When it comes to NeuroGrid, who would you say is responsible for security?\\nI7: Everybody really. </excerpt>
</document_reference>
<document_reference name="Users responsible for reminding medics of their responsibility" contributor="SF" document="Moral responsibility GT concept" >
<excerpt>The bottom line is that with the medical data we remind them that it\\\'s their problem because they are the PI and, obviously, a psychiatrist is not going to know the ins and outs of firewalls and things like IP tables and you wouldn\\\'t expect them to. \\nWe see it as our job to tell them what the problem is and to remind them that they are the PI so if something goes wrong it is definitely on their hands. \\nIt\\\'s a bit of an odd thing that they rely on us to do it in that case.</excerpt>
</document_reference>
<document_reference name="Background contributes likelihood of ethical approval." contributor="SF" document="Operational context GT concept" >
<excerpt>I would assume that within the ethical approval for a particular problem or study, there will be some sense of who is involved in the study and who is allowed to use the data. \\nIt depends on what your background is when you make an application for ethical approval. \\nIt tends to depend on how broad and general the ethical approval is. \\nSo, medics making ethical approvals tend to get a fairly broad sweep of who can access the data ; they get quite a lot of latitude on who they allow to access the data. \\nIf you are a researcher from other areas, you tend to get a very tight control on who can and can\\\'t access the data. \\nA lot of it is down to ethics committees. </excerpt>
</document_reference>
<document_reference name="Users unaware of security until it gets in the way." contributor="SF" document="Operational peer perception GT concept" >
<excerpt>I think the users are very unaware of it, unless they come up against something which doesn\\\'t let them access something they shouldn\\\'t be able to access. </excerpt>
</document_reference>
<document_reference name="Developers perceive security issues." contributor="SF" document="Operational peer perception GT concept" >
<excerpt>Some people who are developing applications based on our system notice a lot. \\nWe recently had a data site they were able to access, but they didn\\\'t think they should be able to access it, so that\\\'s quite a high level of knowledge for someone who is developing an application.</excerpt>
</document_reference>
<document_reference name="Infrastructure team have complete security expertise." contributor="SF" document="Operational peer perception GT concept" >
<excerpt>We have every security aspect in the Oxford team. \\nWhat they have is access control and they are the only people who issue certificates and they check access control. \\nEverything is within one group. </excerpt>
</document_reference>
<document_reference name="System security is reasonable" contributor="SF" document="Operational peer perception GT concept" >
<excerpt>Generally it is pretty good, but it is not completely without its problems. \\nGenerally, as far as projects go, it has been pretty reasonable. \\nAs we work quite closely with the toolkit team based over in XX, they use the portal on a day-to-day basis. \\nAs we have been collecting data, it has only really been the last couple of months that we\\\'ve really engaged with the portal. \\nI think, generally speaking, it has been reasonable. </excerpt>
</document_reference>
<document_reference name="Preferable to offer clear guidelines to users" contributor="SF" document="Procedural control GT concept" >
<excerpt>The best thing to do is just make things clear and give people clear guidance about what they need to do.</excerpt>
</document_reference>
<document_reference name="Preferable to provide lots of information about what needs to be done and how." contributor="SF" document="Procedural control GT concept" >
<excerpt>The best way is to provide lots and lots of information, telling them what it is you want to achieve and what needs to be done to achieve it. </excerpt>
</document_reference>
<document_reference name="The system cannot be designed faster than the project." contributor="SF" document="Requirements perception GT concept" >
<excerpt>You can\\\'t really design it faster than it has. \\nI think there were a few problems with the project as it was setup in the first place. </excerpt>
</document_reference>
<document_reference name="Portal security design was a compromise." contributor="SF" document="Requirements perception GT concept" >
<excerpt>That was the one specifically on NeuroGrid, as the portal design really didn\\\'t take into account of his requirements for security, so they came to some compromise. </excerpt>
</document_reference>
<document_reference name="Disparity between requirements and prototype arose during meetings on different themes." contributor="SF" document="Requirements perception GT concept" >
<excerpt>We would have regular meetings on different themes. \\nThere were some on security specifically, which was where the disparity between the requirements in psychosis and the initial version of the prototype came up. </excerpt>
</document_reference>
<document_reference name="Requirements were complete before the ticketing system was examined." contributor="SF" document="Requirements perception GT concept" >
<excerpt>There were regular meeting for technologists and I wasn\\\'t always present but, we had completed the requirements phase before they started looking at the ticketing system [C] was working on. </excerpt>
</document_reference>
<document_reference name="Many ideas came from another project which resolving issues in a different way." contributor="SF" document="Requirements perception GT concept" >
<excerpt>Most of what I\\\'ve got came from other project which had the same issues, but they had gone further in resolving them in different ways. \\nIn NeuroGrid, in a sense, did the standard thing in most respects.</excerpt>
</document_reference>
<document_reference name="Agreeing by predicting was wrong." contributor="SF" document="Requirements perception GT concept" >
<excerpt>It was just a case of getting people to agree on what they want in this database, to try to predict what kind of research they would try to be doing in the next year, or the next several years. \\nIt was just the wrong way to do things.</excerpt>
</document_reference>
<document_reference name="Infrastructure concerns are straightforward." contributor="SF" document="Requirements perception GT concept" >
<excerpt>\\\"As far as we\\\'re concerned, at our level it is relatively straightforward ; \\\"\\\"we have some data, let\\\'s move it around\\\"\\\". Higher up, the more interesting stuff about what people do with that data, that was going to be taken care of by a workflow toolkit.\\\"</excerpt>
</document_reference>
<document_reference name="Teams do not know what they wanted." contributor="SF" document="Requirements perception GT concept" >
<excerpt>It is slightly difficult for the computing team at Oxford as they are trying to get us what we want, and we don\\\'t exactly know what it is we want. \\nSometimes that geographical distance and sometimes just working in different teams means that it takes time for them to get an understanding of what we want, and for us to get an understanding of what we want and be able to communicate that effectively. </excerpt>
</document_reference>
<document_reference name="Projects initially asked what assets they had." contributor="SF" document="Requirements perception GT concept" >
<excerpt>We asked the questions in the early days about security, which we\\\'ve asked on all projects. \\nThese are \\\"what assets have you got?\\\" and \\\"what constraints do you want to put on those assets?\\\" </excerpt>
</document_reference>
<document_reference name="Perceived workflows of what the system could provide varied." contributor="SF" document="Requirements perception GT concept" >
<excerpt>We got them to draw up workflow and document what they thought the system could provide for them. \\nThis varied from somewhere just to run your image analysis techniques to \\\"we want it to be our data archive\\\", which came as a bit of a shock when we responded with \\\"that\\\'s now possible, we can\\\'t be available 24-7 and hold your primary source of data for clinical trials - that\\\'s not what the grid is about\\\".</excerpt>
</document_reference>
<document_reference name="No guarantee that users are not doing things they should not." contributor="SF" document="Responsibility GT concept" >
<excerpt>because we don\\\'t capture the data, we have no guarantee that the people who are doing all the things that they should. \\nWe don\\\'t want to be responsible for this.</excerpt>
</document_reference>
<document_reference name="Experts in different fields do what is normal to them." contributor="SF" document="Sub-cultures GT concept" >
<excerpt>Experts from different areas work in that field together and they do stuff which is normal for them. \\nWhen you come from a different background, you don\\\'t know what to do with it. \\nThat has to be overcome. </excerpt>
</document_reference>
<document_reference name="Cross over between fields is a need for something like NeuroGrid." contributor="SF" document="Sub-cultures GT concept" >
<excerpt>There are 3 exemplars and the cross-over between them is that they all need something like NeuroGrid. \\nThe actually things they are doing are quite different. </excerpt>
</document_reference>
<document_reference name="Each exemplar has their own processes and standards." contributor="SF" document="Sub-culture norms GT concept" >
<excerpt>Every exemplar had to come up with their own way of getting imaging in. \\nEvery exemplar has different standards they need to apply and different sources. </excerpt>
</document_reference>
<document_reference name="Specific steps are followed for anonymising data." contributor="SF" document="Sub-culture norms GT concept" >
<excerpt>The first part is can any data be exported at all. \\nBehind the scene, all this imaging data is kept in a local archive and the people who manage the archive carry out preliminary steps to limit the amount of patient data that can be correlated to the images themselves. \\nIt is hard to say what the DICOM files might contain, so you have to be fairly strict about getting rid of stuff, as there are all kinds of variation about format. \\nOne file might contain a patient\\\'s name, or the physician\\\'s name, or the radiographer\\\'s name. \\nSo, there is a preliminary step, which is done by the people who manage the archive. \\nWhen it becomes time to actually export it from outside, to go outside our firewall, that is where I come in and that is where NeuroGrid is affected. </excerpt>
</document_reference>
<document_reference name="All exemplar sites have agreed anonymisation rules." contributor="SF" document="Sub-culture norms GT concept" >
<excerpt>we came up with a set of rules of our own. \\nThe stroke exemplar covers two institutions ; there is this group here in Edinburgh and there is another group at the University of Nottingham. \\nIt all comes down to anonymising the files, so we have agreed what our anonymisation rules will be and everybody signed off.</excerpt>
</document_reference>
<document_reference name="Security conscious users craft solid policies." contributor="SF" document="Sub-culture perception GT concept" >
<excerpt>I know some people on the project who definitely think about it and if they craft the policy it will be rock solid. But there are other people on the project who wouldn\\\'t.</excerpt>
</document_reference>
<document_reference name="Data sensitive users refuse algorithmic workflow access." contributor="SF" document="Sub-culture perception GT concept" >
<excerpt>In NeuroGrid, they brought together three groups of people who had radically different views on security and different types of data. \\nWe have one person whose data is all about potential schizophrenics. \\nThat is very sensitive data as a lot of these people aren\\\'t schizophrenics but have a very high probability of becoming one. \\nThat is bad information to get out into the field because of insurance issues or because people won\\\'t employ them. \\nSo, his ethics are very strict to the extent that he never wanted his data to leave the server. He would only allow processed results to leave. \\nAs it turned out, the whole workflow side of the project never happened as you can\\\'t run an algorithm across his data, but he was really pushing for ultra-strict security where you would have to process the data to such an extent that it was useless for identification, whereas other people put data on the system and don\\\'t care who sees it. \\nThe fact that it was a closed group of only 40 people, who would be happy to turn all the access control off if they could.</excerpt>
</document_reference>
<document_reference name="Security conscious users reluctant to provide access." contributor="SF" document="Sub-culture perception GT concept" >
<excerpt>For example, because of the nature of the images owned by psychosis exemplar, they are very reluctant, correctly, to release their images. \\nSo, getting access to their node is very difficult, as they don\\\'t want to release their images. </excerpt>
</document_reference>
<document_reference name="Some users focus only on secure data transfer." contributor="SF" document="Sub-culture perception GT concept" >
<excerpt>Some of them are very tight, others say \\\"well, as long as the data is securely transferred and it comes back, we\\\'re fine with it\\\"</excerpt>
</document_reference>
<document_reference name="Some users will reuse study data for another." contributor="SF" document="Sub-culture values GT concept" >
<excerpt>I was once at a meeting where it was apparent that once the data is collected, people decide they want to use it for another study. \\nThis could go beyond what the patient signed for.</excerpt>
</document_reference>
<document_reference name="Remit of data sometimes go further than originally agreed." contributor="SF" document="Sub-culture values GT concept" >
<excerpt>I went to one of these meetings and there was a problem, which had nothing to do with MRI imaging, where some data was given that may have been used for something like an abortion. \\nThe person who gave that data might be a Christian who certainly doesn\\\'t want this. \\nThis is an example of an instance where the remit has gone further than that originally specified and people who gave their consent might have said they wouldn\\\'t give their consent. </excerpt>
</document_reference>
<document_reference name="People fight their own project corners" contributor="SF" document="Sub-culture values GT concept" >
<excerpt>That means you 3 different projects stuck onto the same project. \\nThe effort is in different places so that people are fighting their own corner.</excerpt>
</document_reference>
<document_reference name="Obligations made before data uploaded to NeuroGrid." contributor="SF" document="Sub-culture values GT concept" >
<excerpt>we have to meet our obligations before the data ever goes to NeuroGrid. \\nSo, I would fall down in my obligations if I let any patient data go out to NeuroGrid.</excerpt>
</document_reference>
<document_reference name="Doctors want scans and data in an easily accessible way." contributor="SF" document="Sub-culture values GT concept" >
<excerpt>From an NHS side, as a doctor, it would be great to have scans and data in an easily accessible way, as that\\\'s the best for the patients. \\nWe are stopped from doing this for the patients as there are people who would like to get hold of this data. \\nThere is that conflict.</excerpt>
</document_reference>
<document_reference name="infrastructure not funded by clinical trials" contributor="SF" document="Sub-culture values GT concept" >
<excerpt>That is what they are paid to do. \\nWhen you fund a clinical trial, it is very rare that you have anything built into the grant to fund any IT infrastructure. </excerpt>
</document_reference>
<document_reference name="Users funded to do science not IT." contributor="SF" document="Sub-culture values GT concept" >
<excerpt>These are not IT specialists, they are scientists and not experts in computing. \\nThe mistake we are making, from a research funding perspective, is that we are not funding them to do the IT and infrastructure, we are funding them to do good science and get papers out. \\nThis is a side issue, but the consequences of things going wrong are huge. </excerpt>
</document_reference>
<document_reference name="Data schemas would be both across exemplars and exemplar specific" contributor="SF" document="Sub-cultural design artifacts GT concept" >
<excerpt>The idea was there would be a core data schema which would go across the 3 exemplars, and there would also be exemplar specific schemas. </excerpt>
</document_reference>
<document_reference name="NeuroGrid never handles potentially identifiable data." contributor="SF" document="Security context GT concept" >
<excerpt>Even though the NeuroGrid system was designed to handle potentially identifiable patient data in a secure way, we would never do it because of the context we work in. \\nConcerns about security are fairly minimal, our main concern about security was that we had a framework and it worked. </excerpt>
</document_reference>
<document_reference name="Focus on middleware rather than data and apps." contributor="SF" document="Security diffusion GT concept" >
<excerpt>Our focus here is purely middleware and people elsewhere worry about the data and the applications. </excerpt>
</document_reference>
<document_reference name="Data provider responsibility to decide data access policy." contributor="SF" document="Security diffusion GT concept" >
<excerpt>Firstly, we genuinely believe it is up to the data providers to determine what the access control policy should be. </excerpt>
</document_reference>
<document_reference name="Users duplicate credentials as they move around." contributor="SF" document="Security erosion GT concept" >
<excerpt>I4: Certificates have their problems. \\nIt is pretty well known that people end up duplicating their certificate everywhere as they move around...\\nI3: Writing down their password...\\nI4: Leaving them on other peoples computers.\\nI5: But this is the same with any mechanism. \\nPeople leave their passwords lying around, people have the same passwords and use their dogs name for a password. It is a common problem.</excerpt>
</document_reference>
<document_reference name="Users share credentials with trusted colleagues." contributor="SF" document="Security erosion GT concept" >
<excerpt>They would keep it so that there were the certificates, so only people from NeuroGrid could access it, but they would happily give certificates out willy-nilly. \\nAnyone they thought would be alright, they would say \\\"alright\\\".</excerpt>
</document_reference>
<document_reference name="Users do not care if browser session shared." contributor="SF" document="Security erosion GT concept" >
<excerpt>They don\\\'t care if someone else is using the browser, although you can\\\'t protect them if they save their password and automatically come up to a page like amazon and their username and password is already filled in. </excerpt>
</document_reference>
<document_reference name="Shortcuts taken to move data quicker." contributor="SF" document="Security erosion GT concept" >
<excerpt> I think one of the problems when you\\\'ve got lots of universities and different institutions is that they all have their own frameworks and guidelines in place for managing data securely. \\nI think that sometimes it would be much easier if there was a broad consensus if people did things in a similar way and there was an appreciation that data needs to be transferred between sites and this needs to be enabled more easily. \\nI think one of the dangers is that short-cuts are taken as things are so difficult that people say well it\\\'s going to be too difficult to go through this entire process, we need the data more quickly. \\nI don\\\'t think we\\\'ve had that, but I foresee that happening if there was real pressure. \\nFor example, at one of the sites we did have a delay in getting started and it did get completed very quickly. \\nHad it not then we could have run into problems trying to cut through red-tape in order to transfer data securely. \\nYou can imagine a situation where someone says look we just need the data to do this so let\\\'s just take a short cut. \\nI guess that sort of idea of collaboration given more consideration, so data can be transferred around more easily, with the necessary safeguards in place. </excerpt>
</document_reference>
<document_reference name="Getting work done is more important than security." contributor="SF" document="Security erosion GT concept" >
<excerpt>When their workloads are so huge, the first thing they\\\'ve got to do is make sure those patients get their results back. \\nIf there is anything standing in their way, they will try and by-pass it. \\nIt\\\'s not unknown for clinics, hospitals and GP practices for people to share user ids and get onto systems, as the first concern is to get things done. \\nThey can\\\'t wait for people like system administrators to do things like change access rights. </excerpt>
</document_reference>
<document_reference name="Some users have a particular interest in patient confidentiality." contributor="SF" document="Security knowledge GT concept" >
<excerpt>[A] based in [D], and also had a particular interest in patient confidentiality and had an understanding of how it could routinely be abused, suggested that it might be an alternative model. </excerpt>
</document_reference>
<document_reference name="Some users provide guidance in data anonymisation." contributor="SF" document="Security knowledge GT concept" >
<excerpt>He has guided us in what we should be anonymising in the DICOM header. \\nHe is directly involved and has experience of clinical trials before as well. \\nI take the DICOM side / eNos data side from [B].</excerpt>
</document_reference>
<document_reference name="Security controls are a necessary evil." contributor="SF" document="Security perception GT concept" >
<excerpt>I think they are a necessary evil. \\nIt would be great to be able to send data around willy-nilly without giving it any thought, but given the world we are living in ....</excerpt>
</document_reference>
<document_reference name="Security is not bad; it just needs to be clear." contributor="SF" document="Security perception GT concept" >
<excerpt>It is an issue which slows you down. The important thing is that it is not critical or bad to have security; it just needs to be clear.</excerpt>
</document_reference>
<document_reference name="Data access roles defined centrally." contributor="SF" document="Security role GT concept" >
<excerpt>These roles are all defined by Infrastructure so, in a way, they are in charge of making sure the data is not in the wrong hands, by the certificates. </excerpt>
</document_reference>
<document_reference name="Users speak to colleagues for technical support." contributor="SF" document="Social-network support GT concept" >
<excerpt>I probably would use [C] as my first port of call. \\nWe both deal with the same area, Stroke, and I do respect his technical knowledge and ability. \\nI probably would check with him to see if he has the same issues, or any comments or guidance. I haven\\\'t really had any issues.</excerpt>
</document_reference>
<document_reference name="One user has responsibility for examining what is permissable and providing guidance." contributor="SF" document="Social-network support GT concept" >
<excerpt>We have [A] and one of this person\\\'s specific roles is to look into what is permissible and what\\\'s not permissible and to really give us guidance on that. \\nWe are really quite fortunate as other centres, not necessarily within this project have not had this.</excerpt>
</document_reference>
<document_reference name="Preferrable to try things out first and get feedback later." contributor="SF" document="Social-network support GT concept" >
<excerpt>Without any feedback there was nothing I could do. \\nThis is why I said earlier that the easiest solution was to try things out and then go on the phone and ask [A] to get feedback straight away. </excerpt>
</document_reference>
<document_reference name="Users are supplied with a certificate" contributor="SF" document="Socialisation GT concept" >
<excerpt>A lot of users access NeuroGrid through the portal, which helps as all the instructions are on it. \\nBasically, I give them a certificate and they go to the portal and off they go ; this leads them through everything they need. </excerpt>
</document_reference>
<document_reference name="Users email for a certificate when data owners grant access to the data." contributor="SF" document="Socialisation GT concept" >
<excerpt>I think they would have to send an email to [C] to get a certificate for themselves, after us saying it\\\'s ok for them to have access to our data. \\nThey literally give them a certificate to give them access to NeuroGrid and then they should get access to our data. \\nIt should be that simple I think.</excerpt>
</document_reference>
<document_reference name="Users are authorised by an exemplar sponsor." contributor="SF" document="Socialisation GT concept" >
<excerpt>Normally, they will need sponsorship from one of the exemplars, there is Dementia, Stroke and Psychosis ; there is an investigator for each exemplar. \\nSo, to begin with, they will need to be authorised by that person. \\nAt that point, we can give them a certificate to access the system and we will probably discuss with the data owner any ramifications about what access they should have and that kind of thing. \\nWe then give them a certificate and some instructions and they are on their way.</excerpt>
</document_reference>
<document_reference name="Users need to have technical ability to use the applications." contributor="SF" document="Socialisation GT concept" >
<excerpt>Most of what we develop is designed to be used by technical people developing end-user applications. \\nIt is not designed for end-users to use. \\nSo, it is reasonable to expect that the people we are developing for has a certain amount of technical ability and to be able to understand how to use the APIs we provide and the sample code we gave them.</excerpt>
</document_reference>
<document_reference name="Guest certificates provided as obtaining personal certificates is too cumbersome." contributor="SF" document="Socialisation GT concept" >
<excerpt>The reason we have the guest certificate is that the process of obtaining the personal certificate was very difficult as it involved you calling people in Oxford. \\nThey send a certificate over email, but they don\\\'t send the password. \\nYou have to call them, or you have to setup a secure email account. \\nIn both cases this is difficult. \\nWe had people on the NeuroGrid project where, after a year or so, said \\\"we never go around to calling Douglas to get the password, so we lost the password and we don\\\'t know what it is\\\". </excerpt>
</document_reference>
<document_reference name="Users are provided an API and example code." contributor="SF" document="Socialisation GT concept" >
<excerpt>We give them API docs and some instructions and an example of how to create a client interface. \\nThe people who have done that are quite technical and they have no trouble at all.</excerpt>
</document_reference>
<document_reference name="General information about security would be useful." contributor="SF" document="Socio-technical measure GT concept" >
<excerpt>Some general information about why security is there would be useful, although the BBC is already doing some of the work explaining why it is necessary. It is easier to convince people when they see the news, as they don\\\'t want their data to be on offer on e-Bay.</excerpt>
</document_reference>
<document_reference name="Certificates need to be uploaded to a web browser." contributor="SF" document="Technical control GT concept" >
<excerpt>To do this, you have to have a certificate on your computer that you have to upload on your web browser</excerpt>
</document_reference>
<document_reference name="Portal is just one part of the system." contributor="SF" document="Technical control GT concept" >
<excerpt>We have a single middleware and the portal is just one part.</excerpt>
</document_reference>
<document_reference name="Users have their own certificates" contributor="SF" document="Technical control GT concept" >
<excerpt>At the very top level, all the users have their own certificates, standard X.509 certificates. \\nThere is a concept of a delegation token, called a ticket, which is passed through the system and lets us know who is making the request. </excerpt>
</document_reference>
<document_reference name="Infrastructure team responsible for securing servers." contributor="SF" document="Technical control responsibility GT concept" >
<excerpt> I take care of all that kind of thing, like making sure the servers themselves are actually secure and they are not going to get broken by someone logging in over ssh. </excerpt>
</document_reference>
<document_reference name="Infrastructure team secure access control policies" contributor="SF" document="Technical control responsibility GT concept" >
<excerpt>I3: System security would be me. \\nIf someone breached an access control policy, then I guess that would be I4.\\nI4: Yes, I guess that would be me. </excerpt>
</document_reference>
<document_reference name="Infrastructure team responsible for security." contributor="SF" document="Technical control responsibility GT concept" >
<excerpt>Based on the definition in the project, the Infrastructure team are responsible for security. If you need a certificate, then you go to the Oxford team and they are maintaining the data node servers, testing the security on them.</excerpt>
</document_reference>
<document_reference name="Infrastructure team developed security framework" contributor="SF" document="Technical control responsibility GT concept" >
<excerpt>The primary responsibility is on the Infrastructure group as they developed the security framework.</excerpt>
</document_reference>
<document_reference name="System security responsibility of infrastructure team and app developers." contributor="SF" document="Technical control responsibility GT concept" >
<excerpt>For responsibility for the tools that enable security to be put in place ; that is the team here. \\nFor making sure that security is implemented all the way through the system, that\\\'s both here and the people developing the toolkit, as they have to carry forward the principles to what they do. </excerpt>
</document_reference>
<document_reference name="Certificates are visible security" contributor="SF" document="Tangible factors GT concept" >
<excerpt>Certificates are a visible access as they have to try to get hold of it and figure out....</excerpt>
</document_reference>
<document_reference name="Access control decisions mainly based on certificates." contributor="SF" document="Tangible factors GT concept" >
<excerpt>It mainly is that certificate and access control decisions which are made, if they are denied access to data</excerpt>
</document_reference>
<document_reference name="Role involves test and validating" contributor="SF" document="User proxy GT concept" >
<excerpt>The best way to describe the role is testing and validating it and giving feedback to the web designer</excerpt>
</document_reference>
<document_reference name="Portal users are experts in their own field." contributor="SF" document="User proxy GT concept" >
<excerpt>To be honest I\\\'m not sure, because the people using the portal are computer experts within each project.</excerpt>
</document_reference>
<persona_characteristic persona="Claire" behavioural_variable="Activities" modal_qualifier="Sometimes" >
<definition>Managers delegate security decisions</definition>
<grounds type="document" reference="Managers do not deal with security" />
<grounds type="document" reference="IS department handed server responsibility to infrastructure team." />
<grounds type="document" reference="Some managerial responsibility for data delegated." />
<grounds type="document" reference="Users responsible for reminding medics of their responsibility" />
<warrant type="document" reference="Principles and ethics committee responsible for approval." />
<rebuttal type="document" reference="Everyone responsible for security" />
</persona_characteristic>
<persona_characteristic persona="Claire" behavioural_variable="Activities" modal_qualifier="Usually" >
<definition>Managers responsible for their users activities</definition>
<grounds type="document" reference="Line manager responsible for user behaviour." />
<warrant type="document" reference="No guarantee that users are not doing things they should not." />
<rebuttal type="document" reference="Managers do not deal with security" />
</persona_characteristic>
<persona_characteristic persona="Claire" behavioural_variable="Aptitudes" modal_qualifier="Sometimes" >
<definition>Medics try to reuse clinical data</definition>
<grounds type="document" reference="Some users will reuse study data for another." />
<grounds type="document" reference="Remit of data sometimes go further than originally agreed." />
<warrant type="document" reference="Background contributes likelihood of ethical approval." />
</persona_characteristic>
<persona_characteristic persona="Claire" behavioural_variable="Aptitudes" modal_qualifier="Usually" >
<definition>Exemplars follow own security norms</definition>
<grounds type="document" reference="Each exemplar has their own processes and standards." />
<grounds type="document" reference="All exemplar sites have agreed anonymisation rules." />
<warrant type="document" reference="Experts in different fields do what is normal to them." />
</persona_characteristic>
<persona_characteristic persona="Claire" behavioural_variable="Attitudes" modal_qualifier="Always" >
<definition>Uploaders legally responsible for what they upload</definition>
<grounds type="document" reference="Uploaders legally obliged to ensure data does not fall into wrong hands." />
<warrant type="document" reference="No guarantee that users are not doing things they should not." />
</persona_characteristic>
<persona_characteristic persona="Claire" behavioural_variable="Attitudes" modal_qualifier="Often" >
<definition>Security a user obstacle not enabler</definition>
<grounds type="document" reference="Background contributes likelihood of ethical approval." />
<grounds type="document" reference="Users unaware of security until it gets in the way." />
</persona_characteristic>
<persona_characteristic persona="Claire" behavioural_variable="Attitudes" modal_qualifier="Normally" >
<definition>Ethics governs data access</definition>
<grounds type="document" reference="Principles and ethics committee responsible for approval." />
<grounds type="document" reference="Ethics ensure user does not allow data to leave server." />
<warrant type="document" reference="No guarantee that users are not doing things they should not." />
</persona_characteristic>
<persona_characteristic persona="Claire" behavioural_variable="Attitudes" modal_qualifier="Usually" >
<definition>Other peoples concerns lock down system security</definition>
<grounds type="document" reference="Data access locked down if security concerns." />
<warrant type="document" reference="Perceived workflows of what the system could provide varied." />
</persona_characteristic>
<persona_characteristic persona="Claire" behavioural_variable="Attitudes" modal_qualifier="Possibly" >
<definition>Compromise sacrificed usability for security</definition>
<grounds type="document" reference="Security can affect result times" />
<grounds type="document" reference="More emphasis on security than usability" />
<grounds type="document" reference="Portal security design was a compromise." />
</persona_characteristic>
<persona_characteristic persona="Claire" behavioural_variable="Attitudes" modal_qualifier="Often" >
<definition>Research and development does not mix</definition>
<grounds type="document" reference="infrastructure not funded by clinical trials" />
<grounds type="document" reference="Users funded to do science not IT." />
<warrant type="document" reference="Requirements were complete before the ticketing system was examined." />
</persona_characteristic>
<persona_characteristic persona="Claire" behavioural_variable="Motivations" modal_qualifier="Perhaps" >
<definition>Asset centricity governs ethics in their use.</definition>
<grounds type="document" reference="Users responsible for anonymisation." />
<grounds type="document" reference="Asset security an exemplar responsibility." />
<warrant type="document" reference="Medics get broad sweep of who can access data." />
</persona_characteristic>
<persona_characteristic persona="Matt" behavioural_variable="Activities" modal_qualifier="Always" >
<definition>Infrastructure team responsible for securing their systems</definition>
<grounds type="document" reference="Infrastructure team secure access control policies" />
<grounds type="document" reference="Infrastructure team developed security framework" />
<rebuttal type="document" reference="Infrastructure team responsible for security." />
</persona_characteristic>
<persona_characteristic persona="Matt" behavioural_variable="Activities" modal_qualifier="Maybe" >
<definition>Security design taken seriously because data is.</definition>
<grounds type="document" reference="Middleware security is taken seriously" />
<grounds type="document" reference="Security designed in line with functionality" />
<warrant type="document" reference="Data access locked down if security concerns." />
</persona_characteristic>
<persona_characteristic persona="Matt" behavioural_variable="Activities" modal_qualifier="Always" >
<definition>Access control governed centrally due to criticality</definition>
<grounds type="document" reference="Security controls are a necessary evil." />
<grounds type="document" reference="Security is not bad; it just needs to be clear." />
<warrant type="document" reference="Data access roles defined centrally." />
</persona_characteristic>
<persona_characteristic persona="Matt" behavioural_variable="Activities" modal_qualifier="Always" >
<definition>Infrastructure team responsible for infrastructure security only</definition>
<grounds type="document" reference="No guarantee that users are not doing things they should not." />
<grounds type="document" reference="Focus on middleware rather than data and apps." />
<warrant type="document" reference="Data provider responsibility to decide data access policy." />
</persona_characteristic>
<persona_characteristic persona="Matt" behavioural_variable="Aptitudes" modal_qualifier="Possibly" >
<definition>Users only controllable via their roles</definition>
<grounds type="document" reference="No guarantee that users are not doing things they should not." />
<warrant type="document" reference="Data access roles defined centrally." />
</persona_characteristic>
<persona_characteristic persona="Matt" behavioural_variable="Attitudes" modal_qualifier="Sometimes" >
<definition>Security reinforces perceptions of data</definition>
<grounds type="document" reference="Security conscious users reluctant to provide access." />
<grounds type="document" reference="Some users focus only on secure data transfer." />
<warrant type="document" reference="Experts in different fields do what is normal to them." />
</persona_characteristic>
<persona_characteristic persona="Matt" behavioural_variable="Attitudes" modal_qualifier="Possibly" >
<definition>Users responsible for their security</definition>
<grounds type="document" reference="Users responsible for anonymisation." />
<grounds type="document" reference="Asset security an exemplar responsibility." />
<warrant type="document" reference="No guarantee that users are not doing things they should not." />
</persona_characteristic>
<persona_characteristic persona="Matt" behavioural_variable="Attitudes" modal_qualifier="Possibly" >
<definition>Certificates are recognisable security for different exemplars</definition>
<grounds type="document" reference="Cross over between fields is a need for something like NeuroGrid." />
<grounds type="document" reference="Certificates are visible security" />
</persona_characteristic>
<persona_characteristic persona="Matt" behavioural_variable="Attitudes" modal_qualifier="Usually" >
<definition>Infrastructure easier to work with than exemplars.</definition>
<grounds type="document" reference="Data schemas would be both across exemplars and exemplar specific" />
<warrant type="document" reference="Infrastructure concerns are straightforward." />
</persona_characteristic>
<persona_characteristic persona="Matt" behavioural_variable="Motivations" modal_qualifier="Usually" >
<definition>Exemplars concerned only with their own interests</definition>
<grounds type="document" reference="People fight their own project corners" />
<grounds type="document" reference="Users funded to do science not IT." />
<warrant type="document" reference="Experts in different fields do what is normal to them." />
</persona_characteristic>
<persona_characteristic persona="Matt" behavioural_variable="Skills" modal_qualifier="Always" >
<definition>Securing system includes securing environment</definition>
<grounds type="document" reference="FLOSS versions checked to ensure system remains secure." />
<grounds type="document" reference="Machines storing confidential data need to be locked down." />
<grounds type="document" reference="Security controls are a necessary evil." />
</persona_characteristic>
<persona_characteristic persona="Matt" behavioural_variable="Skills" modal_qualifier="Always" >
<definition>Infrastructure architecture based on previous experience.</definition>
<grounds type="document" reference="Architecture leveraged experience from past projects." />
<grounds type="document" reference="Many ideas came from another project which resolving issues in a different way." />
</persona_characteristic>
<persona_characteristic persona="Tom" behavioural_variable="Attitudes" modal_qualifier="Possibly" >
<definition>Compromise is preferrable to total agreement</definition>
<grounds type="document" reference="Portal security design was a compromise." />
<grounds type="document" reference="Agreeing by predicting was wrong." />
<grounds type="document" reference="Teams do not know what they wanted." />
<warrant type="document" reference="NeuroGrid was needed long before it was usable." />
</persona_characteristic>
<persona_characteristic persona="Tom" behavioural_variable="Attitudes" modal_qualifier="Usually" >
<definition>Useful security overridden by medics</definition>
<grounds type="document" reference="Medics get broad sweep of who can access data." />
<grounds type="document" reference="Security controls are a necessary evil." />
</persona_characteristic>
<persona_characteristic persona="Tom" behavioural_variable="Attitudes" modal_qualifier="Maybe" >
<definition>Everyone understands security through use</definition>
<grounds type="document" reference="Portal is a frame of reference" />
<grounds type="document" reference="Metaphors helped people express ideas." />
<grounds type="document" reference="Security is not bad; it just needs to be clear." />
</persona_characteristic>
<persona_characteristic persona="Tom" behavioural_variable="Attitudes" modal_qualifier="Usually" >
<definition>Clear security reliant on knowledgeable users</definition>
<grounds type="document" reference="Some users have a particular interest in patient confidentiality." />
<grounds type="document" reference="Some users provide guidance in data anonymisation." />
<warrant type="document" reference="Security is not bad; it just needs to be clear." />
</persona_characteristic>
<persona_characteristic persona="Tom" behavioural_variable="Motivations" modal_qualifier="Usually" >
<definition>Workflows should not let you do what is not appropriate.</definition>
<grounds type="document" reference="Perceived workflows of what the system could provide varied." />
<grounds type="document" reference="NeuroGrid never handles potentially identifiable data." />
</persona_characteristic>
<persona_characteristic persona="Tom" behavioural_variable="Motivations" modal_qualifier="Possibly" >
<definition>Security is a necessary evil</definition>
<grounds type="document" reference="Users share credentials with trusted colleagues." />
<grounds type="document" reference="Security controls are a necessary evil." />
<rebuttal type="document" reference="Getting work done is more important than security." />
</persona_characteristic>
<persona_characteristic persona="Tom" behavioural_variable="Motivations" modal_qualifier="Possibly" >
<definition>Disagreement motivates dominant security</definition>
<grounds type="document" reference="Middleware security is taken seriously" />
<grounds type="document" reference="Data should be moved around only by those with access to it." />
<warrant type="document" reference="Technology and institutions constrain data transfers between universities." />
<warrant type="document" reference="Teams do not know what they wanted." />
</persona_characteristic>
<persona_characteristic persona="Tom" behavioural_variable="Motivations" modal_qualifier="Usually" >
<definition>Developers responsible for hiding dangerous actions from users</definition>
<grounds type="document" reference="API hides details from users." />
<warrant type="document" reference="No guarantee that users are not doing things they should not." />
</persona_characteristic>
<task name="Upload data" author="Shamal Faily" code="UD" assumption_task="FALSE" >
<objective>Upload data</objective>
<task_environment name="Psychosis" >
<dependencies>Claire's workstation is properly set-up to access the NeuroGrid portal. Claire has permission to upload data</dependencies>
<task_persona persona="Claire" duration="Minutes" frequency="Daily_-_Weekly" demands="Low" goal_conflict="Medium" />
<task_concern asset="Clinical data" />
<task_concern asset="Portal" />
<task_concern asset="Client workstation" />
<narrative>Claire wants to analyse a data set, in relation to other data sets on NeuroGrid. She anonymises her data to the extent that as much personalised data is removed as possible, but not to the extent that her analysis software will fail. She then uploads this data, tagging this as available only to members of her exemplar.</narrative>
<consequences>None</consequences>
<benefits>None</benefits>
</task_environment>
<task_environment name="Stroke" >
<dependencies>Tom's workstation is properly set-up to access the NeuroGrid portal. Tom has permission to upload data.</dependencies>
<task_persona persona="Tom" duration="Minutes" frequency="Daily_-_Weekly" demands="High" goal_conflict="Medium" />
<task_concern asset="Clinical data" />
<task_concern asset="Portal" />
<task_concern asset="Client workstation" />
<narrative>Tom wants to analyse a data set, in relation to other data sets on NeuroGrid. He anonymises his data using the anonymisation guidelines within his exemplar, before creating an archive of the data-set to upload. He then uploads this data, tagging this as available only to members of his clinical exemplar.</narrative>
<consequences>None</consequences>
<benefits>None</benefits>
</task_environment>
</task>
<task name="Download data" author="Shamal Faily" code="DD" assumption_task="FALSE" >
<objective>Download data</objective>
<task_environment name="Psychosis" >
<dependencies>Permission to login to NeuroGrid. Permission to download data. Acknowledgement has been sent that results are available for download.</dependencies>
<task_persona persona="Claire" duration="Seconds" frequency="Hourly_or_more" demands="Low" goal_conflict="High" />
<task_concern asset="Analysis data" />
<task_concern asset="Portal" />
<task_concern asset="Web-browser" />
<task_concern asset="Client workstation" />
<narrative>After NeuroGrid finishes executing a workflow, checks are run on the data to ensure that the results have been anonymised. When these checks indicate that the results have been sanitised, a message is sent to Claire, the workflow submitter, that the workflow results are available for download. On receiving this message, Claire logs into NeuroGrid and downloads the results to her personal area.</narrative>
<consequences>None</consequences>
<benefits>None</benefits>
</task_environment>
<task_environment name="Stroke" >
<dependencies>Permission to login to NeuroGrid. Permission to download data. Acknowledgement has been sent that results are available for download.</dependencies>
<task_persona persona="Tom" duration="Minutes" frequency="Daily_-_Weekly" demands="Low" goal_conflict="High" />
<task_concern asset="Analysis data" />
<task_concern asset="Portal" />
<task_concern asset="Web-browser" />
<task_concern asset="Client workstation" />
<narrative>After NeuroGrid finishes executing a workflow, a message is sent to Tom, the workflow submitter, that the workflow results are available for download. On receiving this message, Tom logs into NeuroGrid and downloads the results to his personal area.</narrative>
<consequences>None</consequences>
<benefits>None</benefits>
</task_environment>
</task>
<task name="Issue User Certificate" author="Shamal Faily" code="IUC" assumption_task="FALSE" >
<objective>Issue User Certificate</objective>
<task_environment name="Core Technology" >
<dependencies>Prospective users have been made aware of the importance of clinical data security by their sponsoring exemplars. Prospective users have a sponsor to authorise their request.</dependencies>
<task_persona persona="Matt" duration="Hours_or_longer" frequency="Hourly_or_more" demands="Medium" goal_conflict="High" />
<task_concern asset="User certificate" />
<task_concern asset="Access Control Policy" />
<task_concern asset="Personal certificate" />
<narrative>Matt receives an email request from a prospective user asking for access to NeuroGrid. Shortly after receiving this email, Matt begins the process of verifying the user's identity. This involves speaking to user to ascertain whethe the email sender and the person been spoken to are one and the same. During this conversation, Matt establishes who the user's sponsor is and telephones him/her to also verify their identity. While speaking to the sponsor, Matt asks for information about what this user should have access to be emailed to him, together with the telephone number of the user.</narrative>
<consequences>None</consequences>
<benefits>None</benefits>
</task_environment>
</task>
</usability>
<goals>
<domainproperty name="Secure data analysis" type="Hypothesis" originator="Shamal Faily" >
<definition>We assume that the process of analysing data once it has been uploaded to NeuroGrid is secure.</definition>
</domainproperty>
<domainproperty name="Secure workflow submission" type="Hypothesis" originator="Shamal Faily" >
<definition>We assume the process of submitting workflows to a NeuroGrid node is secure.</definition>
</domainproperty>
<domainproperty name="Infrastructure knowledge" type="Hypothesis" originator="Shamal Faily" >
<definition>NeuroGrid API users have a working knowledge of the NeuroGrid infrastructure, and the security mechanisms used by it.</definition>
</domainproperty>
<domainproperty name="Physical infrastructure security" type="Hypothesis" originator="Shamal Faily" >
<definition>The NeuroGrid server nodes are physically secure.</definition>
</domainproperty>
<domainproperty name="Non-federated access control" type="Invariant" originator="Shamal Faily" >
<definition>Access Control Policies are non-federated, although they appear to be.</definition>
</domainproperty>
<goal name="Process clinical data on NeuroGrid" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="High" >
<definition>Uploading clinical data on NeuroGrid, which is then analysed before aggregated results can be downloaded.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None.</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="Medium" >
<definition>Uploading clinical data on NeuroGrid, which is then analysed before aggregated results can be downloaded.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Upload clinical data to NeuroGrid" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="Medium" >
<definition>Prepare and upload data to the NeuroGrid portal.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="Medium" >
<definition>Prepare and upload data to the NeuroGrid portal.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Download analysis data" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="Medium" >
<definition>Download analysis data from NeuroGrid.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="Medium" >
<definition>Download analysis data from NeuroGrid.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Anonymise data" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="High" >
<definition>Anonymise clinical data to remove as many of the traceability links between the data and the volunteer or patient as possible.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="High" >
<definition>Anonymise clinical data to remove as many of the traceability links between the data and the volunteer or patient as possible.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Upload authorisation" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="Medium" >
<definition>Authorisation is obtained to upload clinical data to a NeuroGrid node for analysis.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="Medium" >
<definition>Authorisation is obtained to upload clinical data to a NeuroGrid node for analysis.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="NeuroGrid portal access" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="High" >
<definition>The NeuroGrid portal is accessible from a client workstation.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="High" >
<definition>The NeuroGrid portal is accessible from a client workstation.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Download authorisation" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="High" >
<definition>Authorisation is obtained to download analysis data from a NeuroGrid node for subsequent analysis.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="High" >
<definition>Authorisation is obtained to download analysis data from a NeuroGrid node for subsequent analysis.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Analysis complete acknowledgement" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="Medium" >
<definition>An acknowledgement is sent to the workflow submitter when analysis is complete.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="Medium" >
<definition>An acknowledgement is sent to the workflow submitter when analysis is complete.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="NeuroGrid user authorisation" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="High" >
<definition>Root certificates are only issued to users authorised with the NeuroGrid CA.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="High" >
<definition>Root certificates are only issued to users authorised with the NeuroGrid CA.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Certificate installation" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="High" >
<definition>A User certificate shall be installed in a web-browser before the NeuroGrid portal can be accessible.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="High" >
<definition>A User certificate shall be installed in a web-browser before the NeuroGrid portal can be accessible.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="PreventUnauthorised Certificate Access" originator="SF">
<goal_environment name="Psychosis" category="Prevent" priority="Medium" >
<definition>Under normal operating conditions, the system shall prevent an occurrence of risk Unauthorised Certificate Access.</definition>
<fit_criterion>None</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Prevent" priority="Medium" >
<definition>Under normal operating conditions, the system shall prevent an occurrence of risk Unauthorised Certificate Access.</definition>
<fit_criterion>None</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Prevent unauthorised site access" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="Medium" >
<definition>Prevent access to site resources to anyone unauthorised.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="Medium" >
<definition>Prevent access to site resources to anyone unauthorised.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Prevent Unauthorised PC access" originator="SF">
<goal_environment name="Psychosis" category="Avoid" priority="Medium" >
<definition>Unauthorised access to PCs.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Avoid" priority="Medium" >
<definition>Unauthorised access to PCs.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Verify new staff" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="Medium" >
<definition>Verify the credentials of strangers in the work area.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="Medium" >
<definition>Verify the credentials of strangers in the work area.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Timed login" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="Medium" >
<definition>Automatically log-out PCs if left unattended for long periods.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="Medium" >
<definition>Automatically log-out PCs if left unattended for long periods.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Location-based Authentication" originator="SF">
<goal_environment name="Psychosis" category="Achieve" priority="Medium" >
<definition>Location-based authentication mechanism to supplement the use of user certificates, to ensure users are only authorised from certain nodes.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Achieve" priority="Medium" >
<definition>Host-based authentication mechanism to supplement the use of root certificates, to ensure users are only authorised from certain nodes.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Disallow Multiple Logins" originator="SF">
<goal_environment name="Psychosis" category="Avoid" priority="Medium" >
<definition>Disallow PC logins into multiple workstations.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Avoid" priority="Medium" >
<definition>Disallow PC logins into multiple workstations.</definition>
<fit_criterion>TBC</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Secure data transmission" originator="SF">
<goal_environment name="Psychosis" category="Maintain" priority="High" >
<definition>Data uploaded to and downloaded from the NeuroGrid repository shall be secure.</definition>
<fit_criterion>None</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Maintain" priority="High" >
<definition>Data uploaded to and downloaded from the NeuroGrid repository shall be secure.</definition>
<fit_criterion>None</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Multi-Factor Authentication" originator="SF">
<goal_environment name="Psychosis" category="Maintain" priority="High" >
<definition>Authentication to NeuroGrid shall not rely solely on Digital Certificates</definition>
<fit_criterion>None</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Maintain" priority="High" >
<definition>Authentication to NeuroGrid shall not rely solely on Digital Certificates</definition>
<fit_criterion>None</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Data-set access" originator="SF">
<goal_environment name="Psychosis" category="Maintain" priority="High" >
<definition>Authenticated users shall obtain authorisation from a data-set owner before an uploaded workflow can access any data within it.</definition>
<fit_criterion>None</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Maintain" priority="High" >
<definition>Authenticated users shall obtain authorisation from a data-set owner before an uploaded workflow can access any data within it.</definition>
<fit_criterion>None</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Upload workflows to NeuroGrid" originator="SF">
<goal_environment name="Psychosis" category="Maintain" priority="Medium" >
<definition>Authenticated users shall be allowed to upload workflows to NeuroGrid.</definition>
<fit_criterion>None</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Maintain" priority="Medium" >
<definition>Authenticated users shall be allowed to upload workflows to NeuroGrid.</definition>
<fit_criterion>None</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<goal name="Download to WebDAV folder" originator="SF">
<goal_environment name="Psychosis" category="Maintain" priority="High" >
<definition>Processed analysis data shall be downloadable only to an authorised user's WebDAV folder.</definition>
<fit_criterion>None</fit_criterion>
<issue>None</issue>
</goal_environment>
<goal_environment name="Stroke" category="Maintain" priority="High" >
<definition>Processed analysis data shall be downloadable only to an authorised user's WebDAV folder.</definition>
<fit_criterion>None</fit_criterion>
<issue>None</issue>
</goal_environment>
</goal>
<obstacle name="Unauthorised portal access" originator="Shamal Faily" >
<obstacle_environment name="Psychosis" category="Vulnerability" >
<definition>A user not authorised by a CA to accesses the NeuroGrid portal.</definition>
</obstacle_environment>
<obstacle_environment name="Stroke" category="Vulnerability" >
<definition>A user not authorised by a CA to accesses the NeuroGrid portal.</definition>
</obstacle_environment>
</obstacle>
<obstacle name="Certificate sharing" originator="Shamal Faily" >
<obstacle_environment name="Psychosis" category="Vulnerability" >
<definition>Certificates are shared with users not authorised to access the NeuroGrid portal.</definition>
<concern name="Personal certificate" />
</obstacle_environment>
<obstacle_environment name="Stroke" category="Vulnerability" >
<definition>Certificates are shared with users not authorised to access the NeuroGrid portal.</definition>
<concern name="Personal certificate" />
</obstacle_environment>
</obstacle>
<obstacle name="Control web browser" originator="Shamal Faily" >
<obstacle_environment name="Psychosis" category="Confidentiality_Threat" >
<definition>Unauthorised user obtains access to a web-browser configured for NeuroGrid access.</definition>
</obstacle_environment>
<obstacle_environment name="Stroke" category="Confidentiality_Threat" >
<definition>Unauthorised user obtains access to a web-browser configured for NeuroGrid access.</definition>
</obstacle_environment>
</obstacle>
<obstacle name="XSS Exploit" originator="Shamal Faily" >
<obstacle_environment name="Psychosis" category="Integrity_Threat" >
<definition>Access to web-browser obtained via a Cross-Site Scripting Exploit.</definition>
</obstacle_environment>
<obstacle_environment name="Stroke" category="Integrity_Threat" >
<definition>Access to web-browser obtained via a Cross-Site Scripting Exploit.</definition>
</obstacle_environment>
</obstacle>
<obstacle name="Fraudulant certificate application" originator="Shamal Faily" >
<obstacle_environment name="Psychosis" category="Accountability_Threat" >
<definition>An attacker successfully makes an application for a NeuroGrid root certificate.</definition>
</obstacle_environment>
<obstacle_environment name="Stroke" category="Accountability_Threat" >
<definition>An attacker successfully makes an application for a NeuroGrid root certificate.</definition>
</obstacle_environment>
</obstacle>
<obstacle name="Access user certificate" originator="Shamal Faily" >
<obstacle_environment name="Psychosis" category="Vulnerability" >
<definition>User certificates are shared and end up in the hands of an unauthorised user.</definition>
</obstacle_environment>
<obstacle_environment name="Stroke" category="Vulnerability" >
<definition>User certificates are shared and end up in the hands of an unauthorised user.</definition>
</obstacle_environment>
</obstacle>
<obstacle name="Unattended workstation access" originator="Shamal Faily" >
<obstacle_environment name="Psychosis" category="Accountability_Threat" >
<definition>An attacker obtains access to an unattended NeuroGrid workstation.</definition>
</obstacle_environment>
<obstacle_environment name="Stroke" category="Accountability_Threat" >
<definition>An attacker obtains access to an unattended NeuroGrid workstation.</definition>
</obstacle_environment>
</obstacle>
<obstacle name="Unauthorised clinical data access" originator="Shamal Faily" >
<obstacle_environment name="Psychosis" category="Confidentiality_Threat" >
<definition>Attacker obtains unauthorised access to clinical data.</definition>
</obstacle_environment>
</obstacle>
<obstacle name="Fraudulant ethical approval"