Secure by Design at ACCU 2019

Security is an ever more important topic for system designers. As our world becomes digital, today’s safely-hidden back office system is tomorrow’s public API, open to anyone on the Internet with a hacking tool and time on their hands. So 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.

Transcript

1. 1
   SECURE BY DESIGN
   Security Design Principles for the Working Architect
   Eoin Woods

   Endava

   @eoinwoodz
   

   View Slide

2. BACKGROUND
   • Eoin Woods
   • CTO at Endava (technology services, ~5000 people)
   • 10 years in product development - Bull, Sybase, InterTrust
   • 10 years in capital markets applications - UBS and BGI
   • Software dev engineer, then architect, now CTO
   • Author, editor, speaker, community guy
   2
   

   View 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
   • Improving application security in real teams
   3
   

   View Slide

4. 4
   REVISITING SECURITY
   

   View 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 Slide

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

   View Slide

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

   View Slide

8. DATA BREACHES 2009 - 2011
   8
   

   View Slide

9. DATA BREACHES 2015 - 2018
   9
   

   View Slide

10. 10
    TODAY’ S THREAT LANDSCAPE
    System interfaces on the Internet
    Introspection of APIs
    Attacks being “weaponised”
    Today’s internal app is tomorrow’s “digital channel”
    https://cybermap.kaspersky.com/
    

    View Slide

11. 11
    SECURITY PRINCIPLES
    

    View Slide

12. SECURITY DESIGN PRINCIPLES
    What is a “principle” ?
    a fundamental truth or proposition serving as the foundation for
    belief or action [OED]
    We define 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 Slide

13. SECURITY DESIGN PRINCIPLES
    • There are many sets of security design principles
    • Viega & McGraw (10), OWASP (10), NIST (33), 

    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
    • www.viewpoints-and-perspectives.info
    13
    

    View Slide

14. A SYSTEM TO BE SECURED
    14
    

    View Slide

15. 15
    10 KEY SECURITY PRINCIPLES
    

    View Slide

16. TEN KEY SECURITY PRINCIPLES
    • Assign the least privilege
    possible
    • Separate responsibilities
    • 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
    16
    

    View 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
    Tradeoff Less convenient; less efficient; more complexity
    Example
    Run server processes as their own users with exactly
    the set of privileges they require
    17
    

    View Slide

18. 2 - SEPARATE RESPONSIBILITIES
    Why?
    Achieve control and accountability, limit the impact of
    successful attacks, make attacks less attractive
    Principle
    Separate and compartmentalise responsibilities and
    privileges
    Tradeoff
    Development and testing costs; operational complexity:
    troubleshooting more difficult
    Example
    “Payments” module administrators have no access to
    or control over “Orders” module features
    18
    

    View Slide

19. 2 - SEPARATE RESPONSIBILITIES
    19
    

    View Slide

20. 3- 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
    certificates, credentials or network controls
    20
    

    View Slide

21. 3- 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
    certificates, credentials or network controls
    21
    

    View Slide

22. 3- 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
    Reject untrusted RPC connections, authenticate clients,
    check 3rd party components, scan your open source
    22
    

    View Slide

23. 3 - TRUST CAUTIOUSLY
    23
    https://www.aspectsecurity.com/research-presentations/the-unfortunate-reality-of-insecure-libraries
    

    View Slide

24. 3 - TRUST CAUTIOUSLY
    24
    Sonatype 2018 State of the Software Supply Chain Report
    

    View Slide

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

    View Slide

26. 4- SIMPLEST SOLUTION POSSIBLE
    Why?
    Security requires understanding of the design -
    complexity rarely understood - simplicity allows analysis
    Principle
    Actively design for simplicity - avoid complex failure
    modes, implicit behaviour, unnecessary features, …
    Tradeoff
    Hard decisions on features and sophistication;
    Needs serious design effort to be simple
    Example
    Does the system really need dynamic runtime
    configuration via a custom DSL?
    The price of reliability is the pursuit of the utmost simplicity - C.A.R. Hoare
    26
    

    View Slide

27. 5 - AUDIT SENSITIVE EVENTS
    Why?
    Provide record of activity, deter wrong doing, provide a
    log to reconstruct the past, provide a monitoring point
    Principle
    Record all security significant events in a tamper-
    resistant store
    Tradeoff Performance; operational complexity; dev cost
    Example
    Record changes to "core" business entities in an append-
    only store with (user, ip, timestamp, entity, event)
    27
    

    View Slide

28. 5 - AUDIT SENSITIVE EVENTS
    28
    

    View Slide

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

    View Slide

30. 7 - NEVER RELY ON OBSCURITY
    Why?
    Hiding things is difficult - someone is going to find
    them, accidentally if not on purpose
    Principle
    Assume 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
    30
    

    View Slide

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

    View Slide

32. 8 - DEFENCE IN DEPTH
    32
    

    View Slide

33. 9 - NEVER INVENT SECURITY TECH
    Why?
    Security technology is difficult to create - avoiding
    vulnerabilities is difficult
    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
    33
    

    View Slide

34. 9 - NEVER INVENT SECURITY TECHNOLOGY
    34
    

    View Slide

35. 9 - NEVER INVENT SECURITY TECHNOLOGY
    35
    

    View Slide

36. 10 - 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
    Significant effort required; often reveals problems at
    the least convenient moment!
    Example
    Data privacy threat => encrypted communication but
    with unencrypted database storage and backups
    36
    

    View Slide

37. TEN KEY SECURITY PRINCIPLES
    • Assign the least privilege
    possible
    • Separate responsibilities
    • 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
    37
    

    View Slide

38. 38
    SECURITY IN REAL TEAMS
    

    View Slide

39. SOME COMMON CONCERNS
    39
    Where do we start?
    Who is involved?
    What tools do we use?
    Can we do this with agile?
    Will this cost a lot?
    Won’t this slow everything down?
    

    View Slide

40. SOME OBSERVATIONS
    • Some individuals will find it fascinating, some will hate it
    • Teams will need guidance and inspiration
    • Teams need to own their security process
    • But a clearly defined starting point and standards very valuable
    • A clear roadmap helps to avoid overload
    40
    

    View Slide

41. SOME USEFUL TACTICS
    • Form a group of security champions - invest in them
    • involve many roles (BA, developer, tester, architect, …)
    • Communicate importance of security from the top
    • and from the customer
    • Make the right thing the easy thing
    • checklists and templates, clear guidance, packaged tools
    • Be prepared for the process to take time
    41
    

    View Slide

42. USUALLY A GRADUAL PROCESS
    42
    SECURITY AWARE TEAM
    INFORMED APPLICATION SECURITY TEAM
    COMPETENT APPLICATION SECURITY TEAM
    EXPERT APPLICATION SECURITY TEAM
    NO SECURITY PRACTICE
    

    View Slide

43. EXAMPLE CAPABILITY PLAN
    43
    AWARE
    INFORMED
    COMPETENT
    EXPERT
    OWASP “Top 10”
    Security Principles Basic Sec Coding Pen Testing
    Security Requirements
    Release Criteria
    Risk Assessment
    Secure Coding Static Scanning
    OSS Mgmt
    Basic Secure Design
    Threat Modelling
    Sec Code Reviews
    Secure Design
    Incident Simulations
    Active Threat Assessment
    Attack Surface Analysis
    Dynamic Analysis
    Fuzz Testing
    Red Teams
    Continual Improvement
    

    View Slide

44. OWASP SAMM
    44
    http://www.opensamm.org
    

    View Slide

45. MICROSOFT SDL
    45
    https://www.microsoft.com/en-us/sdl/
    

    View Slide

46. 46
    TO RECAP …
    

    View Slide

47. TEN KEY SECURITY PRINCIPLES
    • Assign the least privilege
    possible
    • Separate responsibilities
    • 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
    47
    

    View Slide

48. GETTING TEAMS DOING IT
    48
    Continuous Process
    Towards Secure SDLC
    

    View Slide

49. REFERENCES
    • UK Government NCSC Security Principles:

    https://www.ncsc.gov.uk/guidance/security-design-principles-digital-services-main
    • NIST Engineering Principles for IT Security:

    http://csrc.nist.gov/publications/nistpubs/800-27A/SP800-27-RevA.pdf
    • Short intro to McGraw’s set:

    http://www.zdnet.com/article/gary-mcgraw-10-steps-to-secure-software/
    • OWASP Principles set:

    https://www.owasp.org/index.php/Category:Principle
    49
    

    View Slide

50. BOOKS
    50
    

    View Slide

51. 51
    Eoin Woods

    Endava

    eoin.woods@endava.com
    
    @eoinwoodz
    THANK YOU
    

    QUESTIONS?
    

    View Slide