Slide 1

Slide 1 text

EOIN WOODS JANUARY 2024 Secure by Design the architect’s guide to security design principles

Slide 2

Slide 2 text

EOIN WOODS: BACKGROUND • Endava’s Chief Engineer (in London since 2015) • 10+ years in products - Bull, Sybase, InterTrust • 10 years in capital markets - UBS and BGI • Software developer, then architect • Author, editor, speaker, community guy 2

Slide 3

Slide 3 text

CONTENT • What is security and why do we care? • What are security principles, why are they useful? • Security design principles • 10 important principles useful in practice 3

Slide 4

Slide 4 text

4 REVISITING SECURITY

Slide 5

Slide 5 text

REVISITING SECURITY • We all know security is important - but why? • protection against malice, mistakes and mischance • theft, fraud, destruction, disruption • Security is a risk management business • loss of time, money, privacy, reputation, advantage • insurance model - balance costs against risk of loss 5

Slide 6

Slide 6 text

ASPECTS OF SECURITY PRACTICE Secure Application Design Secure Application Implementation Secure Infrastructure Design Secure Infrastructure Deployment Secure System Operation & Security Ops 6

Slide 7

Slide 7 text

DATA BREACHES 2006 - 2009 7 http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/

Slide 8

Slide 8 text

DATA BREACHES 2010 - 2013 8 http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/

Slide 9

Slide 9 text

DATA BREACHES 2015 - 2018 9 http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/

Slide 10

Slide 10 text

DATA BREACHES 2019 - 2022 10 http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/ 1,000,000,000 500,000,000

Slide 11

Slide 11 text

11 SECURITY PRINCIPLES

Slide 12

Slide 12 text

SECURITY DESIGN PRINCIPLES What is a “principle” ? a fundamental truth or proposition serving as the foundation for belief or action [OED] We de fi ne a security design principle as …. a declarative statement made with the intention of guiding security design decisions in order to meet the goals of a system 12

Slide 13

Slide 13 text

SECURITY DESIGN PRINCIPLES • There are many sets of security design principles • Viega & McGraw (10), OWASP (12), NIST (30), NCSC (44), Cliff Berg (185) … • Many similarities between them at fundamental level • I have distilled 10 key principles as a basic set • these are brief summaries for slide presentation • Based on a set from www.viewpoints-and-perspectives.info 13

Slide 14

Slide 14 text

A SYSTEM TO BE SECURED 14

Slide 15

Slide 15 text

15 10 KEY SECURITY PRINCIPLES

Slide 16

Slide 16 text

TEN KEY SECURITY PRINCIPLES • Use the least privilege possible • Trust cautiously • Simplest solution possible • Audit sensitive events • Fail securely & use secure defaults • Never rely upon obscurity • Implement defence in depth • Never invent security technology • Find the weakest link • Minimise the attack surface 16

Slide 17

Slide 17 text

1- LEAST PRIVILEGE Why? Broad privileges allow malicious or accidental access to protected resources Principle Limit privileges to the minimum for the context, separate and compartmentalise scope & responsibility Tradeoff Less convenient; more development and testing complexity; more operational complexity Example Run server processes as their own users with only the privileges they require and compartmentalise application privileges by functional area 17

Slide 18

Slide 18 text

1 - LEAST PRIVILEGE 18

Slide 19

Slide 19 text

2 - TRUST CAUTIOUSLY Why? Many security problems caused by inserting malicious intermediaries in communication paths Principle Assume unknown entities are untrusted, have a clear process to establish trust, validate who is connecting Tradeoff Operational complexity (particularly failure recovery); reliability; some development overhead Example Don't accept untrusted API connections, use client certi fi cates, credentials or network controls, secure your software supply chain (e.g. open source) 19

Slide 20

Slide 20 text

2 - TRUST CAUTIOUSLY Why? Many security problems caused by inserting malicious intermediaries in communication paths Principle Assume unknown entities are untrusted, have a clear process to establish trust, validate who is connecting Tradeoff Operational complexity (particularly failure recovery), reliability; some development overhead Example Don't accept untrusted RMI connections, use client certi fi cates, credentials or network controls 20

Slide 21

Slide 21 text

2 - TRUST CAUTIOUSLY Why? Many security problems caused by inserting malicious intermediaries in communication paths Principle Assume unknown entities are untrusted, have a clear process to establish trust, validate who is connecting Tradeoff Operational complexity (particularly failure recovery); reliability; some development overhead Example Don't accept untrusted API connections, use client certi fi cates, credentials or network controls, scan OSS 21

Slide 22

Slide 22 text

2 - TRUST CAUTIOUSLY What is connecting to our services? What are we connecting to? What can access our database? 22 What libraries do we use? From where? Who are you? How do we know?

Slide 23

Slide 23 text

3 - SIMPLEST SOLUTION POSSIBLE Why? Security requires understanding of the design - complexity is rarely understood well - simplicity allows analysis Principle Actively design for simplicity - choose simple mechanisms, avoid complex failure modes and implicit behaviour, … Tradeoff Hard decisions on design choices and sophistication; Simplicity needs serious design effort Example Does the system really need dynamic runtime con fi guration via a custom DSL? The price of reliability is the pursuit of the utmost simplicity - C.A.R. Hoare 23

Slide 24

Slide 24 text

4 - AUDIT SENSITIVE EVENTS Why? Provide a record of activity, deter wrong doing, provide a log to reconstruct the past, provide a monitoring point Principle Record all security signi fi cant events in a tamper-resistant store Tradeoff Performance; operational complexity; development cost Example Record changes to "core" business entities in an append- only store including, user, ip, timestamp, entity and event 24

Slide 25

Slide 25 text

4 - AUDIT SENSITIVE EVENTS 25

Slide 26

Slide 26 text

5 - SECURE DEFAULTS & FAIL SECURELY Why? Default passwords, ports & rules are “open doors” Failure and restart states often default to “insecure” Principle Force changes to default security parameters Think through failures - to be secure but recoverable Tradeoff Convenience Example Don’t allow “admin/change_it” user after installation On failure don’t disable or reset security controls 26

Slide 27

Slide 27 text

TEN KEY SECURITY PRINCIPLES • Use the least privilege possible • Trust cautiously • Simplest solution possible • Audit sensitive events • Fail securely & use secure defaults • Never rely upon obscurity • Implement defence in depth • Never invent security technology • Find the weakest link • Minimise the attack surface 27 ✔︎ ✔︎ ✔︎ ✔︎ ✔︎

Slide 28

Slide 28 text

6 - NEVER RELY ON OBSCURITY Why? Hiding things is dif fi cult - someone is going to nd them, accidentally if not deliberately Principle Assume an attacker with perfect knowledge, this forces secure system design Tradeoff Designing a truly secure system takes time and effort Example Assume an attacker will guess a "port knock" network request sequence or a password obfuscation technique 28

Slide 29

Slide 29 text

7 - DEFENCE IN DEPTH Why? Systems do get attacked, breaches do happen, mistakes are made - need to minimise impact Principle Don’t rely on a single point of security, secure every level, stop failures at one level propagating Tradeoff Redundancy of policy; complex permissioning and troubleshooting; can make recovery dif cult Example Access control in UI, services, database, OS 29

Slide 30

Slide 30 text

7 - DEFENCE IN DEPTH 30

Slide 31

Slide 31 text

8 - NEVER INVENT SECURITY TECH Why? Security technology is dif fi cult to create - avoiding vulnerabilities is dif fi cult Principle Don’t create your own security technology - always use a proven component Tradeoff Time to assess security technology; effort to learn it; complexity Example Don’t invent your own SSO mechanism, secret storage or crypto libraries … choose proven components 31

Slide 32

Slide 32 text

8 - NEVER INVENT SECURITY TECHNOLOGY 32

Slide 33

Slide 33 text

8 - NEVER INVENT SECURITY TECHNOLOGY 33

Slide 34

Slide 34 text

9 - SECURE THE WEAKEST LINK Why? "Paper Wall" problem - common when focus is on technologies not threats Principle Find the weakest link in the security chain and strengthen it - repeat! (Threat modelling) Tradeoff Signi fi cant effort required; often reveals problems at the least convenient moment! Example Data privacy threat from encrypted communication but with unencrypted database storage and backups 34

Slide 35

Slide 35 text

10 - MINIMISE THE ATTACK SURFACE Why? Every feature and piece of technology in your system is a possible attack vector; less “things” => less threat Principle Minimise the attack surface of your application by actively minimising features and technologies Tradeoff Rarely what a product owner wants to prioritise, dif fi cult to persuade people to remove anything ! Example Actively work to remove old APIs and data import interfaces (e.g. do you still really need CSV and XML?) 35

Slide 36

Slide 36 text

10 - ATTACK SURFACE 36 ? Minimal services accessible? Simplest con fi guration? ? Minimal software installation? Minmal features? ? Minimal features? Simplest software stack? Simple con fi g? ? Fewest connections types possible? ? Minimal data set?

Slide 37

Slide 37 text

37 TO RECAP …

Slide 38

Slide 38 text

TEN KEY SECURITY PRINCIPLES • Use the least privilege possible • Trust cautiously • Simplest solution possible • Audit sensitive events • Fail securely & use secure defaults • Never rely upon obscurity • Implement defence in depth • Never invent security technology • Find the weakest link • Minimise the attack surface 38

Slide 39

Slide 39 text

A FEW REFERENCES • UK Government NCSC Security Principles: https://www.ncsc.gov.uk/guidance/security-design-principles-digital-services-main • NIST Principles for Trustworthy Secure Design, in Appendix E of this document: https://csrc.nist.gov/pubs/sp/800/160/v1/r1/ fi nal • Short introduction to Viega and McGraw’s set: https://www.sintef.no/en/digital/sos-agile/posts-sos-agile/tst2/ • OWASP Principles from the Developer Guide project: https://owasp.org/www-project-developer-guide/draft/foundations/security_principles 39

Slide 40

Slide 40 text

BOOKS 40

Slide 41

Slide 41 text

41 Eoin Woods
 Endava
 [email protected] www.eoinwoods.info @eoinwoodz Thank you … questions?