Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Can We Make Software Better?

TS/2015/131-B

Presentation by Trustworthy Software Initiative (TSI) to meeting of BCS (Shropshire)

  • Be the first to comment

  • Be the first to like this

Can We Make Software Better?

  1. 1. Trustworthy Software Initiative 1 Can We Make Software Better? [TS/2015/131‐B | Issue 1.0 | 2016‐03‐02] Ian Bryant TSI Technical Director © Copyright 2003-2016 BCS Shropshire 2016-03-03
  2. 2. Historical Perspective • Babylonian Code of Hammurabi  (~1780BCE) is earliest known  example of code of conduct for craftsmen, engineers and  builders • Hippocrates ‐ ancient Greek philosopher and “father of  medicine” lays out the Oath ‐ a moral framework for the  conduct of doctors and other healthcare professionals in late  5th Century BCE • 1907 collapse of 1st Quebec Railway Bridge was traced to lack  of due diligence in design, implementation and compliance  Emergence of Codes of Ethics in Professional Engineering  bodies, which typically includes Risk and Trustworthiness  UK’s Royal Academy of Engineering and Engineering Council  now maintain core Statement of Ethical Principles [TS/2015/131-B] © Copyright 2003-2016 2
  3. 3. Elements of Trustworthiness [TS/2015/131-B] © Copyright 2003-2016 3 • Aristotle's Ῥητορική (Treatise on Rhetoric) suggests   that  a  speaker's   ethos (Greek root  for ethics)   is   based   on  the  listener's   perception   of  3  things:    intelligence;    character (reliability,    honesty);   and   goodwill   (favourable  intentions  toward  the  listener) • This was refined† as a model for Trustworthiness as  being based upon:  o Ability (Organisational / individual Competence) o Integrity (Honesty in thought and action) o Benevolence (Approach to Externalities) † “An Integrative Model of Organizational Trust”; Mayer R C, Davis J H, Schoorman F D; The Academy of  Management Review, Vol. 20, No. 3 (Jul., 1995), pp. 709‐734
  4. 4. UK’s Modern Engineering Principles • UK’s Royal Academy of Engineering and Engineering  Council publish consolidated Statement of Ethical  Principles • This includes:  – Acting in a reliable and trustworthy manner – Giving due weight to all relevant facts and published  guidance, and the wider public interest – Identifying, evaluating, and quantifying risks – Being alert to ways in which work might affect others,  holding health and safety paramount [TS/2015/131-B] © Copyright 2003-2016 4
  5. 5. Risk The Engineering Council elaborates on risk principles  in Guidance on Risk for the Engineering Profession: 1. Apply professional and responsible judgement and take a  leadership role  2. Adopt a systematic and holistic approach to risk  identification, assessment and management 3. Comply with legislation and codes, but be prepared to  seek further improvements 4. Ensure good communication with the others involved  5. Ensure that lasting systems for oversight and scrutiny are  in place 6. Contribute to public awareness of risk [TS/2015/131-B] © Copyright 2003-2016 5
  6. 6. Facets of Technical Trustworthiness [TS/2015/131-B] © Copyright 2003-2016 6 Trustworthiness Safety The ability of the system to operate without harmful states Reliability The ability of the system to deliver services as specified Availability The ability of the system to deliver services when requested Resilience The ability of the system to transform, renew, and recover in timely response to events Security The ability of the system to remain protected against accidental or deliberate attacks • No de jure or de facto definition of Trustworthiness • TSI therefore extended de facto definition of  Dependability by addition of Resilience 
  7. 7. Implicit Requirements (1) • Typical Customers only really understand and/or care  about Explicit (Functional) Requirements • For instance, a Local Authority may want a Bridge • The expressed Functional Requirement may only be: • Vector (end points  direction, length) • Capacity (number of lanes) New Bridge [TS/2015/131-B] © Copyright 2003-2016 7
  8. 8. Implicit Requirements (2) • In most industries, in addition to meeting Functional  Requirements, Supplier gives due weight to all  relevant guidance {c.f. Ethical Principles}, including  Non‐Functional Requirements (NFR) • For the Bridge, this will include: • Strength (of components and overall) • Clearance required over river • Known Failures modes ‐ ‐ ‐ ‐ ‐ ‐ ‐ ‐ ‐ ‐ > • The software industry does not have a good track  record of addressing the NFR for Trustworthiness 1st Tacoma Narrows Bridge 1940-11-07 [TS/2015/131-B] © Copyright 2003-2016 8
  9. 9. The Cyber Ecosystem: “IOCT” [TS/2015/131-B] © Copyright 2003-2016 9 • Digital technology  realms – IT: Information  Technologies – OT: Operational  Technologies – CT: Consumer  Technologies • “IOCT” • Generic functions are Processing, Storage and Forwarding • Can be either:  – Data‐centric (mainly OT); and/or  – Information‐centric (mainly IT/CT)
  10. 10. Emergent Challenges to Software  • Current global Technological / Societal challenges: – Distributed application platforms and services (“Cloud”) – Internet of Things (IoT) / Machine to Machine (M2M) – Mobile Devices and Lightweight operating systems – Consumerisation / Bring‐Your‐Own‐Device (BYOD) – Commoditisation in previously closed architectures – Consolidation for energy efficiency (Low Carbon / Green) • These are likely to present Disruptive Challenges,  fundamentally deepening dependence on Software [TS/2015/131-B] © Copyright 2003-2016 10
  11. 11. Software in the Cyber Ecosystem [TS/2015/131-B] © Copyright 2003-2016 11
  12. 12. Software Reuse 12 [TS/2015/131-B] © Copyright 2003-2016
  13. 13. Limitations on Perfection • Normal Accident  Theory (NAT)  – “Normal Accidents”,             C Perrow, 1984 – “Normal Accidents with  Y2K Postscript”, C Perrow,  1999 • No complex, tightly  coupled systems,  humans design, build  and run can be  perfect 13 [TS/2015/131-B] © Copyright 2003-2016
  14. 14. Making Software Better ? [TS/2015/131-B] © Copyright 2003-2016 14 “99 little bugs in the code on the box, 99 little bugs in the code, … …, you take one down, you patch it around, 101 little bugs in the code!”
  15. 15. The Art Of The Possible • For any large scale and/or complex System,  “perfection” (i.e. the complete absence of Defects) is  typically an illusion, for a variety of reasons including: – “Combinatorial explosion” – Chaotic behaviours – Emergent properties • Nonetheless Good Engineering Practice across all  domains remains to minimise avoidable Defects, noting  the Pareto Principle (“80:20”) • Software should be treated like every other  engineering activity 15 [TS/2015/131-B] © Copyright 2003-2016
  16. 16. Trustworthiness Failure: Safety [TS/2015/131-B] © Copyright 2003-2016 16 Toyota Motor Corp said on Wednesday it would recall about 625,000 hybrid cars  globally to fix a software glitch that could, in limited cases, shut down the hybrid  system while the car is being driven. Business News | Wed Jul 15, 2015 1:21am EDT Toyota recalls 625,000 hybrid cars globally for software glitch TSI Case Study •TS621‐1406  •“Software error that could result in a loss of vehicle power”
  17. 17. Trustworthiness Failure: Reliability [TS/2015/131-B] © Copyright 2003-2016 17 TSI Case Study •TS621‐1301  •“Spreadsheet Validation”
  18. 18. Trustworthiness Failure: Availability [TS/2015/131-B] © Copyright 2003-2016 18 A history of outages and technical meltdowns A total of 600,000 transfers were affected by a technical glitch in RBS Group banks RBS, Ulster, Coutts and NatWest accounts on 17 June, leaving thousands of customers without benefits, wages or other payments TSI Case Study •TS621‐1403  •“RBS – Software Update failure”
  19. 19. Trustworthiness Failure: Resilience [TS/2015/131-B] © Copyright 2003-2016 19 TSI Case Study •TS621‐1405  •“Denver International Airport Baggage Handling System” Denver Airport had ambitious plans to route passenger’s bags to and from aircraft without significant  human intervention. The system was called the Denver International Airport Baggage System (DIA ABS).  It ran over budget by almost 30%, with an actual cost of $250M vs. $195M planned, and completion  was delayed 18 months. These delays themselves are bad, but not disastrous. The problem was that the  system did not function as intended The Failure of Denver International Airport’s Automated Baggage System
  20. 20. Trustworthiness Failure: Security [TS/2015/131-B] © Copyright 2003-2016 20 The recent data breach at Adobe that exposed user account information and prompted a flurry  of password reset emails impacted at least 38 million users, the company now says. It also  appears that the already massive source code leak at Adobe is broadening to include the  company’s Photoshop family of graphical design products. TSI Case Study •TS621‐1404  •“Adobe Systems data breach”
  21. 21. Software Incident Impact • Software problems are high cost to economy:  – US Government National Institute of Standards &  Technology (NIST) ~$60 billion / year to US alone  – No definitive figure for UK / worldwide • Software a major source of IT project failure: – University of Oxford Saïd Business School / McKinsey 2011;  Standish Chaos Reports 2004 onwards; et al • Software bugs “source of 90% of ICT Incidents” – (GovCERT‐UK, 2012‐09) • Mitre’s Common Weakness Enumeration (CWE) is a  maintained list of generic software weakness types  – 918 distinct CWEs at v2.4 21 [TS/2015/131-B] © Copyright 2003-2016
  22. 22. Exploiting Weakness • Most modern Malicious Software (MalWare) exploit  Vulnerabilities that are instances of generic Weakness Classes • Timeline of select significant Malware: 22 [TS/2015/131-B] © Copyright 2003-2016 Year Malware Weakness ? Year Malware Weakness ? 1981 Elk Cloner  (Apple)  2001 Code Red I+II /  Nimda (Web)  (Traversal) 1986 Brain  (Boot)  2003 SQL Slammer  (Database)  (Buffer) 1988 Morris  (Worm)  (Buffer) 2004 Sasser (Network)  (Buffer) 1995 Concept  (Macro)  (Mobile code) 2008 Bohmini (Flash)  (Memory) 1996 Staog (Linux)  (Buffer) 2008 Conficker (NetBIOS)  (Crafted  message) 1999 KAK worm (JavaScript)  (Permission) 2012 Flashback  (Mac)  (Array)
  23. 23. Recent Software Weakness 23 [TS/2015/131-B] © Copyright 2003-2016 US Federal Register Volume 80, Number 84 (Friday, May 1, 2015) Yet another “Buffer Overflow”!
  24. 24. Trustworthy Software Requirement • Requirements for Trustworthy Software can arise  from • Explicit (Functional) Requirement for Trustworthiness • Implicit (Non Functional) Requirement (NFR) for  Trustworthiness • Direct NFR for software under consideration • As Collateral NFR from other software in environment • Requirements cover whole IOCT  domain (including  ICS) and activities (Specification, Realisation and Use) • Assurance requirements range from Due Diligence  (all software) to Comprehensive [TS/2015/131-B] © Copyright 2003-2016 24
  25. 25. Challenge – Stovepiped Adversity Views • Few practitioners treat Adversity holistically • Information Security community address Threat – Deterministic model with problems handling Known,  Unknown and Unknowable (KuU) factors – Often ignores Hazards • System Reliability / Safety community address  Hazards – Typically Stochastic model – Approach usually ignores Threat  Trustworthiness approach intended to break down  these stovepipes [TS/2015/131-B] © Copyright 2003-2016 25
  26. 26. Holistic Adversity Treatment [TS/2015/131-B] © Copyright 2003-2016 26 Adversities Risk Trustworthiness Protection Hazards Safety Dependability Threats Security Defence Faults Holistic Stovepiped Focus Approach Goal Treatment ∑ ƒ [Safety; Reliability; Availability;  Resilience; Security]
  27. 27. Software Incidents 27 © Copyright 2003-2012
  28. 28. Trustworthiness and Security Mapping [TS/2015/131-B] © Copyright 2003-2016 28 Security Confidentiality Safety ResilienceReliability Availability I n t e g r i t y
  29. 29. Simplified LifeCycle: “S‐R‐U” [TS/2015/131-B] © Copyright 2003-2016 29 SRD DIS INT REQ DES IMP TSTVAL MAI OPE TRA Specify Realise Use Complex Cycle from ISO/IEC/IEEE 15288 “Systems and software engineering -- System life cycle processes”
  30. 30. UK view of Cyber Risk [TS/2015/131-B] © Copyright 2003-2016 30 • UK “National Risk Register” identifies Cyber Risk as one of the 4 “Tier One” Risks of particular concern: – Hostile Attacks upon UK Cyber Space – Potential shortcomings in the UK’s cyber infrastructure, with the root cause of many shortcomings being untrustworthy software – Actions of cyber terrorists and criminals • National Security Strategy (2010) commits to seeking ways to address Cyber Risk • National Cyber Security Programme (NCSP) being funded 2011‐2016 by central government to address Cyber Risk, across both Public and Private Sectors
  31. 31. Transnational View of Cyber Risk • World Economic Forum "Global Risks"; 9th Edition, January 2014 – Investigates interconnections and interdependencies between global risks – Identifies “Digital disintegration” as one of the most significant such  systemic risks for the next 10 years that need exploration, as the  underlying dynamic of the online world has always been that it is easier to  attack than defend • World Economic Forum "Risk and Responsibility in a Hyperconnected  World"; January 2014 – Supports and expands on “Global Risk” and its “Digital disintegration”  global systemic risks – Identifies need for robust, coordinated system of global cyber resilience to  effectively mitigate the risk to cyber ecosystem – Identifies Top 5 Risks to cyber ecosystem most likely to have a strategic,  negative impact • “Poorly designed [software] code” is one of the Top 5 31 [TS/2015/131-B] © Copyright 2003-2016
  32. 32. Existential View of Cyber Risk “12 Risks That Threaten Human Civilisation” – Global Challenges Foundation, February 2015 – Analysis by TSI reveals that 33% have an explicit or implicit need for  Trustworthy Software 32 [TS/2015/131-B] © Copyright 2003-2016 Risk Type Software Examples Explicit Need Implicit Need Global Systems  Collapse Current Reliable SCADA (Power Grids); Programmed  Trading (Finance) Correct  Performance Synthetic Biology Emergent Use of Genome  Programming Language(s) Correct  Performance Nanotechnology Emergent Control of Autonomy Limitation on  Freedom Correct  Performance Artificial  Intelligence Emergent Control of abilities and  goals Limitation on  Freedom Correct  Performance
  33. 33. Trustworthy Software Initiative Mission [TS/2015/131-B] © Copyright 2003-2016 33 • The Minister for the Cabinet Office stated in respect of the Future Plans for UK’s Cyber Security Strategy in December 2012: “We support and fund the Trustworthy Software Initiative (TSI), which aims to improve cyber security by making software more secure, dependable and reliable, and to educate on why trustworthy software is important” • The Minister of State for Universities and Science amplified this in June 2014: “The Trustworthy Software Initiative (TSI) will help UK companies select the most secure, dependable and reliable software for their needs as well as providing them with the skills to use it effectively”.
  34. 34. TSI Philosophy • Most of the principles and techniques needed for  Trustworthy Software have existed for many years • Application typically confined to higher assurance  requirements of Facets of Trustworthiness as Niches • TSI curates set of common, Pareto (“80:20”)  approaches to Making Software Better, iteratively  using existing learnings for general use in Public Good • For Niche (“20:80”) use, TSI approach complements  existing specialist principles and techniques, allowing  the identification of gaps and enhancements [TS/2015/131-B] © Copyright 2003-2016 34
  35. 35. Trustworthy Components Pillars of Trustworthiness  [TS/2015/131-B] © Copyright 2003-2016 35 Trustworthy Practitioners Trustworthy Organisations Trustworthiness Instruction Trustworthy Software
  36. 36. TSI Targets [TS/2015/131-B] © Copyright 2003-2016 36 • Untrustworthiness of software can arise as: – Weaknesses, which are generic classes of potential  deficiency in software – Vulnerabilities, which are the existence of a generic  weakness(es) in a particular platform – Susceptibilities, which are the confirmed presence of  one or more vulnerability within an implemented  system • TSI attempts to mitigate Weaknesses such that  Vulnerabilities and Susceptibilities do not arise
  37. 37. Benefits of Harmonised Software Trustworthiness • To Demand‐side – de facto or de jure expression of specification, providing risk  reduction, and  a target for compliance • To Supply‐side  – Level playing field, with improved business opportunities – Avoidance of nugatory effort, and reduced cost of doing  business  • To Corpus‐production side – de facto or de jure repository of knowledge, and a target for  compliance • To UK plc – A means for UK to show it leads the way with its trustworthy  software systems and expertise [TS/2015/131-B] © Copyright 2003-2016 37
  38. 38. Trustworthiness & Security Lifecycles [TS/2015/131-B] © Copyright 2003-2016 38 Low-Medium Risk Medium-High Risk
  39. 39. TS Supply‐side Audience Cluster [TS/2015/131-B] © Copyright 2003-2016 39 Where Supply‐side: – Mainstream = “The  Industry” (e.g. Microsoft,  Oracle, ...) – Niche =  Specialist  Industries (e.g. Aviation,  “Security”) but with  Stovepiped Adversity view – Dispersed = Small scale  developers (e.g.  SmartPhone Apps) – Collateral = Developers  don’t consider themselves  as such (e.g. Embedded  components, website CMS  users, spreadsheets, …) – Gap = Suppliers who regard  Adversity Holistically Likely Process-tolerance Likely Trustworthiness-as-Functionality Mainstream Niche CollateralD i s p e r s e d Gap
  40. 40. Trustworthiness Level Definitions • TL0 – Nil – Software trustworthiness not required • TL1 – Essential Practices – Software trustworthiness  delivered in a due diligence manner • TL2 – Assessed Practices – Software trustworthiness  delivered by managed processes • TL3 – Enhanced Practices – Software trustworthiness  delivered by established processes • TL4 – Specialist Practices – Software trustworthiness  delivered by predictable or optimising processes 40 [TS/2015/131-B] © Copyright 2003-2016 Terminology aligned with ISO/IEC 15504 “SPICE”
  41. 41. TS Audience Scale [TS/2015/131-B] © Copyright 2003-2016 41 Indicative world market sizes per TL modelled as a discrete variable mapped against a log scale: if natural, ordinal numbers were used, the TL4 market (M/I only) would be so dominant that all other segments (the TL2 element of M/I; M/E at both TL2 and TL3; N/E at both TL3 and TL4) would not be visible
  42. 42. TSI Audience Applicability [TS/2015/131-B] © Copyright 2003-2016 42 Applicability Risk Segment Approach Goal Metric (No requirement) TL0   Mass  Market  / Implicit  Need  (M/I) TL1 – Fundamental  Practice Baseline (Prescriptive):  “TS Essentials” (TS502‐x) Existence  (MoEx) Mass  Market /  Explicit  Need  (M/E) TL2 – Structured Practices Performance (MoPe) Niche  Market /  Explicit  Need  (N/E) TL3 – Enhanced Practices Comprehensive (Descriptive) BS PAS754:2014 Effectiveness  (MoEf) TL4 – Specialist Practices Operational Effectiveness  (MoOE)
  43. 43. Niche View to augment Existing practices TL 0 Required Trustworthiness Levels (TL) [TSI/2015/131-B] © Copyright 2003-2016 43 Software +  Use  Parameters Risk Analysis No Requirements Organisational  processes Comprehensive  Specification Baseline  Specification Mass Market View for (Pareto) general use TL 3/4 TL 1/2 Prescriptive Approach Descriptive Approach TS Essentials (TS502) BS PAS754 2014
  44. 44. Example of Risk‐based Use of TLs [TSI/2015/131-B] © Copyright 2003-2016 44 RC ‐ Risk Capacity AER ‐ Annualised Expectation of Risk Averse Minimal Cautious Open Hungry Very Low TL3 TL2 TL1 TL1 TL1 Low TL4 TL3 TL2 TL1 TL1 Medium TL4 TL4 TL3 TL2 TL1 High TL4 TL4 TL4 TL3 TL2 Very High TL4 TL4 TL4 TL4 TL3 “Neutral” Default assumption for Supply-side (Sum of predicated Frequency and Duration across all deployments) (To avoid “Moral Hazard” from Negative Externality)
  45. 45. Core Body of Knowledge: Trustworthy Software Framework (TSF) Level 1 Level 2 Level 3 Level 4 Citations Methods Data  Sharing Amount of Detail Typical Audience Low Medium High (Unlimited) Senior Management Middle Management Practitioners [TS/2015/131-B] © Copyright 2003-2016 45 Practitioners
  46. 46. TSF: Choosing a “View” [TS/2015/131-B] © Copyright 2003-2016 46
  47. 47. Programming Languages [TSI/2015/131-B] © Copyright 2003-2016 47
  48. 48. Trustworthy Software Framework  (TSF) – Example of Use Level 0 Title Level 1 Areas Level 2 Groups Level 3 Control Consensus Level 4 Repository e.g.  Citations e.g. TE – Technical e.g. TE.02 – Appropriate Tool Choice e.g. TE.02.10 – Programming Language(s) e.g. ISO/IEC 24772 “Guidance on language selection” Trustworthy Software Framework (TSF) [TS/2015/131-B] © Copyright 2003-2016 48
  49. 49. TSF Controls in the Lifecycle • Fundamental Control Measures – Trustworthy Software  Management System (TSMS) – Trustworthy Software Defect  and Deviation List (TSDDL) • Realisation Control measures – Trustworthy Software  Release Authority (TSRA) – Trustworthy Software  Constraint and Dependency  Model (TSCDM) – Trustworthy Software  Release Notice (TSRN) 49 [TS/2015/131-B] © Copyright 2003-2016 Specification Realisation Use
  50. 50. Trustworthy Software Framework  (TSF) ‐ Applicability • Audiences for the TSF can be summarised as: – Specification : those who collate the requirements for  both Explicit and Implicit characteristics of software to be  acquired – Realisation : those who produce software (a multi‐phase  activity  including design; implementation; integration;  test) – Use: those who operate and/or utilise software • TSF needs to be tailored such that it is applied in a Pragmatic,  Appropriate and Cost Effective (PACE) manner, using  concepts, principles and techniques to suit each environment [TS/2015/131-B] © Copyright 2003-2016 50
  51. 51. 51 [TS/2015/131-B] © Copyright 2003-2016 Standards Coverage / Gaps
  52. 52. Comprehensive TSF Roll‐Out [TS/2015/131-B] © Copyright 2003-2016 52 • TSMS – Trustworthy Software Management System:  instantiation of TSF principles in organisational  context • PAS754:2014 – “Software Trustworthiness – Governance and management – Specification“:  Publicly Available Specification, launched by Minister  for Universities and Science, 10 June 2014
  53. 53. Baseline TSF Roll‐Out [TS/2015/131-B] © Copyright 2003-2016 53 • PAS754:2014 – “Software  Trustworthiness – Governance and  management – Specification“ provides comprehensive, prescriptive  view for higher Trustworthiness  Requirements (TL3/4) • “Trustworthy Software Essentials”  provides entry‐level baseline,  prescriptive approach for lower  Trustworthiness Requirements  (TL1/2) • Released 2 March 2016
  54. 54. Trustworthiness & Security Requirements [TS/2015/131-B] © Copyright 2003-2016 54 TSI / TechForum Patching Videos June 2015 Low-Medium Risk Medium-High Risk TS Essentials ISO/IEC27001BS PAS754 CS Essentials
  55. 55. Select Standards Contribution • ETSI  – EG 101582: Security Testing Case Studies – EG 101583: Security Testing Terminology – EG 203250: Security Assurance Lifecycle • ISO/IEC JTC1  – 27034‐n Application Security Series (6 parts) – 27036‐n Supply Chain Series (4 parts) • ITU X.15nn – CyBEX series • MACCSA – ISF (Information Sharing Framework) • Others still being identified  55 [TS/2015/131-B] © Copyright 2003-2016
  56. 56. Training, Education and Awareness (TEA) • Ministerial Mandate (Cabinet Office, December 2012) specified need to “educate on why trustworthy software is important” • The Training, Education and Awareness (TEA) Work Area consists of three strands: – Education of the future software supply and demand workforce – Training of the current software supply and demand workforce – Awareness for all other elements of the workforce who have some need for software trustworthiness [TS/2015/131-B] © Copyright 2003-2016 56
  57. 57. Integrated Instruction Roadmap (IIR) [TS/2015/131-B] © Copyright 2003-2016 57
  58. 58. Verification .vs. Validation [TS/2015/131-B] © Copyright 2003-2016 58
  59. 59. Verification Approaches [TS/2015/131-B] © Copyright 2003-2016 59 TSI is only looking  at Verification, not   Validation
  60. 60. Questions ? 60 [TS/2015/131-B] © Copyright 2003-2016
  61. 61. Contact 61 [TS/2015/131-B] © Copyright 2003-2016 Ian Bryant Programme Manager & Technical Director T S I TSI Office Cyber Security Centre Room 255 International Manufacturing Centre University of Warwick  University Road, Westwood Heath, Coventry, CV4 7AL, England ian.bryant@uk‐tsi.org +44 300 030 1924 www.uk‐tsi.org

    Be the first to comment

TS/2015/131-B Presentation by Trustworthy Software Initiative (TSI) to meeting of BCS (Shropshire)

Views

Total views

216

On Slideshare

0

From embeds

0

Number of embeds

0

Actions

Downloads

1

Shares

0

Comments

0

Likes

0

×