Security by design revisited

0 downloads 197 Views 1MB Size Report
Nov 3, 2017 - HR, Training budget, awareness, compliance and audit frameworks. ... Do project managers and procurers und
Strategic Research 2017

Security by design revisited In association with TechUK, (ISC)2, EEF - the Manufacturers’ Organisation, and the Trustworthy Software Foundation. Notes and reflections on Workshop 2 Nigel Jones, CEO IAAC, 3rd November 2017 The previous notes gave the following background: Workshop 1 was held on 4th July and was followed by a number of separate individual discussions. These confirmed that there is plenty of advice from numerous sources on how security might be built into product and services, though there is a deficit when thinking about systems of systems. It was decided to proceed with examining the barriers and enablers of adoption of best practice, as the focus for this research. Three key points emerged from the discussion: Firstly, there is a cultural issue that needs to be examined. This should think about people’s expectations and behaviours around the procurement, purchasing, design, development and whole life management of software and systems. Secondly, one group came up with the notion of ‘Build well, Operate well’, that might have traction with a wider community than just the specialist security professional. This seemed to resonate in the workshop as a simple statement that captured the essence of an end-state of ethical good practice, producing better systems and services. Thirdly, there was the concept of ‘paying for the confidence that we can trust technology’. This pointed to the broad economic arguments that shape the two points above. The second workshop on 12 October 2017 sought to exam the relationships between culture, economics and other factors, in aiming to ‘build well and operate well’. To do this, the workshop was facilitated by Lorraine Dodd from Cranfield University and Nigel Jones (IAAC). It used elements of soft systems methodology. By building up a picture of these relationships, it was anticipated that a more targeted set of interventions might be envisaged in the third workshop that could address the adoption problem. The rich pictures developed in three syndicates are included in these notes. To inspire and ground the discussion, the case of Cobots in manufacturing was explored. A number of documents were surveyed which illustrated that safety was a key feature of Cobot procurement, with less attention given to security.

1

Syndicate 1 This syndicate explored business, user and security/ technical stakeholders, and their relationships. The system of interest – the worker and the cobot – sit at the centre of a general working context. Business stakeholders are noted at the top, providing governance functions and leadership, such as HR, Training budget, awareness, compliance and audit frameworks. They also exercise overall oversight of IT functions. Explicit within the picture are the changing job roles of people as their work becomes automated. A range of technical features are noted such as legacy systems, data flows, CSIRT, artificial intelligence, controllers and developers. Syndicate 2 Syndicate two also explored many of the social, technical and governance relationships surrounding the automated cobot. The context for deployment spanned the built environment, manufacturing and personal care. Quality of data, intelligence and standards are all noted in the system, as are the business relationships in a supply chains. This business sub-system includes suppliers, retailers and maintainers. In terms of the user community, the distinction between IT and OT is highlighted, despite the cloud architecture behind both. Syndicate 3 Syndicate three extended their picture over three pages. 3-1 focuses on the environment of the individual developer, influenced by, for example: • • • • • •

Education and training Culture – including ethics Polices – including ethics Project managers and requirements Outputs, users and Return on Investment HR issues such as pay and conditions.

The other pictures examine in some detail the supply chain and the project management process. These relationships include a dynamic based on a number of questions, also represented in the discussion in the other syndicates: • • • • •



Do customers ask for security as part of a product, system or service? Do their customers ask for security as part of a product, system or service? Do procurement teams know how to specify and cost security requirements? Do project managers and procurers understand how security might be maintained within development? How do notions of Time, Cost and Quality impact upon non-functional and security requirements? Note some talk about ‘performance’ rather than quality. This has the danger of focusing on the primary observable function and ignoring non-functional attributes, or background behaviours that do not appear to affect the primary function. Performance has a benefit that it is perhaps easier to quantify than ‘quality, when performance is taken to mean - ‘behaviour’ towards a goal. ‘Minimum viable product’ may be an outcome of contemporary project management and this may tend to exclude features such as security unless demanded by a customer.

2

Discussion and conclusions A number of conclusion emerged in the workshop: 1. Audiences for best practice interventions. There are multiple stakeholders involved in bringing about best practice. This stems from individual developers to governance structures and leadership. Interventions should target across this spectrum with different messages and recognising diverse incentives. 2. Key relationships. There are key relationships important to target in these interventions. These involve procurement teams, project managers and customers. Critical here is that: a. Customers must demand security, and this means their customers too. b. Procurement staff and project managers need to be able to develop and understand security requirements. 3. Artificial intelligence and adaptable systems are pervasive features of future systems, influencing trust relationships and reinforcing the need for good development. Whilst many interventions have focused on improving the quality of engineering and development in the supply side, little has yet been done on the demands aspects of systems. One interesting metaphor emerged during the workshop that is worthy of future examination. This was the analogy of the IoT system as a guide dog (imagine the autonomous vehicle as a guide dog, or smart phone as a guide dog). The relationship between a guide dog and the person with sight loss is one of maintaining ongoing trust, and both adapting to their ways of working and living. In some ways the person with impaired sight has to be trained. Importantly, a lot of work is done up front in designing out unwanted features of the dog. It is this process of getting design right, training, adapting and maintaining ongoing trusted relationships that we might wish to replicate elsewhere. An alternative model was also mentioned during the workshop that extends Time Cost and Quality to Scope, Quality, Implementability, Resources and Timescale (SQIRT), previously used by HM Government. These observations and conclusions will be taken into the third workshop on 5th December. For more information visit www.iaac.org.uk or contact [email protected] , particularly to suggest changes or provide comments on these notes.

3

Syndicate 1

4

Syndicate 2

5

Syndicate 3-1

6

Syndicate 3-2 7

Syndicate 3-3

8