Can We Make Software Better?
•
0 gefällt mir•230 views
TS/2015/131-B Presentation by Trustworthy Software Initiative (TSI) to meeting of BCS (Shropshire)
![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](https://image-private.slidesharecdn.com/ts2015131-bbcsshropshire20160303issue1-1-160315231501/85/slide-1-320.jpg?hdnea=acl=/ts2015131-bbcsshropshire20160303issue1-1-160315231501/85/slide-1-320.jpg*~exp=1714943644~hmac=e3eaf81f91414d91e0be2e41249c8ee869130396c5a8f7967ff55d65b451b541&cb=1458083722)
![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](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (10)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Can We Make Software Better?
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
- 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. 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. 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. 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”
- 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. 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. 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. 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. 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. 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. 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. 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. 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]
- 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. 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. 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. 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. 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. 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. 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
- 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. 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
- 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. 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. 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. 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. 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. 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. 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
- 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. 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. 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
- 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. 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. 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. 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. 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