Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Secure by Design the architect’s guide to security design principles

Secure by Design the architect’s guide to security design principles

Security is an ever more important topic for system designers and the days of hoping that security is someone else’s problem are over.
 The security community has developed a well understood set of principles used to build systems that are secure (or at least securable) by design, but this topic often isn’t included in the training of software developers, assuming that it’s only relevant to security specialists. Then when principles are explained, they are often shrouded in the jargon of the security engineering community and so mainstream developers struggle to understand and apply them. 
In this talk, we will introduce a set of ten key, proven, principles for designing secure systems, distilled from the wisdom of the security engineering community. We’ll explain each principle the context of mainstream system design, rather than in the specialised language of security engineering, explaining how it is applied in practice to improve security.

Eoin Woods

February 11, 2024
Tweet

More Decks by Eoin Woods

Other Decks in Programming

Transcript

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

    View full-size slide

  2. 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

    View full-size slide

  3. 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

    View full-size slide

  4. 4
    REVISITING SECURITY

    View full-size slide

  5. 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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  11. 11
    SECURITY PRINCIPLES

    View full-size slide

  12. 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

    View full-size slide

  13. 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

    View full-size slide

  14. A SYSTEM TO BE SECURED
    14

    View full-size slide

  15. 15
    10 KEY SECURITY PRINCIPLES

    View full-size slide

  16. 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

    View full-size slide

  17. 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

    View full-size slide

  18. 1 - LEAST PRIVILEGE
    18

    View full-size slide

  19. 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

    View full-size slide

  20. 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

    View full-size slide

  21. 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

    View full-size slide

  22. 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?

    View full-size slide

  23. 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

    View full-size slide

  24. 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

    View full-size slide

  25. 4 - AUDIT SENSITIVE EVENTS
    25

    View full-size slide

  26. 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

    View full-size slide

  27. 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
    ✔︎
    ✔︎
    ✔︎
    ✔︎
    ✔︎

    View full-size slide

  28. 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

    View full-size slide

  29. 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

    View full-size slide

  30. 7 - DEFENCE IN DEPTH
    30

    View full-size slide

  31. 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

    View full-size slide

  32. 8 - NEVER INVENT SECURITY TECHNOLOGY
    32

    View full-size slide

  33. 8 - NEVER INVENT SECURITY TECHNOLOGY
    33

    View full-size slide

  34. 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

    View full-size slide

  35. 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

    View full-size slide

  36. 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?

    View full-size slide

  37. 37
    TO RECAP …

    View full-size slide

  38. 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

    View full-size slide

  39. 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

    View full-size slide

  40. 41
    Eoin Woods

    Endava

    [email protected]

    www.eoinwoods.info

    @eoinwoodz
    Thank you … questions?

    View full-size slide