System Security Beyond the Libraries

Security is now important to all of us, not just people who work at Facebook. Most developers think about security in terms of security technologies that they want to apply to their systems, and then ask how secure the system is. From a secure systems perspective, this is the wrong way around. To build a secure system, you need to start from the things that need to be protected and the threats to those resources.

In this session, Eoin dives into the fundamentals of system security to introduce the topics we need to understand in order to decide how to secure our systems.

Transcript

1. Security Beyond the Libraries
   Eoin Woods

   Endava
   
   eoin.woods@endava.com / @eoinwoodz
   

   View Slide

2. Introduction
   2
   

   View Slide

3. Introduction
   • Security is a difficult thing to achieve
   
   • becoming more important all the time
   
   • Development teams often start with technologies
   
   • “SSL” “Spring Security” “SSO” “Roles” “OAuth”
   
   • “FindBugs” “FxCop” “Fortify” “Tripwire”
   
   • This is completely the wrong way around
   
   • need to understand your risks before finding solutions
   
   • technology is only part of the solution
   
   • In this talk we discuss how to base security on risks
   3
   

   View Slide

4. Caveats
   • This talk is introductory in nature
   
   • some things aren’t talked about at all
   
   • some things are just introduced
   
   • Talk is for system developers not security engineers
   
   • there are many subtleties that are skipped over
   
   • some things are simplified to their essentials
   
   • you still probably need a security specialist
   
   • Don’t talk much technologies or coding practice
   
   • these fundamentals need to be in place first
   4
   

   View Slide

5. Introducing Security
   5
   

   View Slide

6. The Need for Security
   • We need systems that are dependable in spite of
   
   • Malice
   
   • Error and
   
   • Mischance
   
   • People are sometimes bad, stupid or just unlucky
   
   • System security attempts to mitigate these situations
   
   • Anything of value may attract unwelcome attention
   
   • Theft, Fraud, Destruction, Disruption
   6
   

   View Slide

7. The Need for Security
   • Why do we care about these factors?
   
   • Each of them implies a loss of some sort
   
   • Time
   
   • Money
   
   • Privacy
   
   • Reputation
   
   • Advantage
   7
   

   View Slide

8. What is Security?
   • Security is the business of managing risks
   
   • Security is a type of insurance
   
   • Balances cost and effort against risk of loss
   
   • Some basic terminology
   
   • resources - things of value that (may) need protection
   
   • actors - people (“entities”) interacting with the system
   
   • policies - the rules to control access to the resources
   
   • threats - the reason that the rules may be broken
   8
   

   View Slide

9. What is Security?
   • Security is multi-dimensional
   
   • People
   
   • Users, administrators, security experts (and … attackers)
   
   • Process
   
   • Design, operation, control, monitoring, …
   
   • Technology
   
   • What to apply, how to use it, how to integrate it
   
   Security is not a product -- it's a process
   Bruce Schneier
   You’re only as strong as your weakest link!
   9
   

   View Slide

10. Risks, Threats and Attacks
    • Vulnerability = a weakness in a security mechanism
    
    • Threat = Vulnerability + Attacker + Motivation
    
    • Attack = when the attacker puts a plan into action
    
    • Risk = threat x likelihood x impact
    10
    Source: OWASP
    

    View Slide

11. Key Security Requirements
    • Confidentiality (or Privacy)
    
    • Prevent unauthorised access to information
    
    • Integrity
    
    • Prevent tampering or destruction
    
    • Availability
    
    • Prevent disruption to users of systems
    
    • Accountability (or “non-repudiation”)
    
    • Know who does what, when
    
    11
    

    View Slide

12. Securing Systems
    12
    

    View Slide

13. Validate
    Securing a System
    Understand
    Analyse
    Mitigate
    Model the System
    Investigate the
    Environment
    Resources &
    Policy
    Threat Modelling
    Minimise Attack
    Surface
    Security
    Countermeasures
    Security Reviews Security Testing
    

    View Slide

14. Modelling the System and Environment
    Understand
    System Context
    System Architecture
    

    View Slide

15. Resources - Identify Value
    • What is valuable is often self-evident
    
    • client information … damaging if lost
    
    • what is of value for an external attacker?
    
    • configuration files … reveal network topologies
    
    • Operations as well as data
    
    • viewing a payment might be fine

    … releasing a payment is another question!
    
    • May require fine-grained consideration
    
    • HR data - work phone numbers vs home address
    15
    Analyse
    

    View Slide

16. Policy - Define the Required Controls
    • Security policy is a security specification
    
    • controls and guarantees needed in the system
    
    • WHO will use the system? (principals)
    
    • WHAT will they work on? (resource types)
    
    • and WHAT may they do? (actions on resources)
    16
    Analyse
    

    View Slide

17. Security Policy
    Clients Orders
    Refunds

    <= £100
    Refunds

    > £100
    Onshore
    Service Agents
    Create, View,

    Modify

    (Un)Suspend
    All
    Create, View,
    Authorise
    View
    Offshore
    Service Agents
    View,
    (Un)Suspend
    View, Cancel View View
    Supervisors All All All
    Create, View,
    Cancel
    Finance View View
    View,
    Authorise
    All
    Analyse
    

    View Slide

18. Threat Modelling
    • Threat is a possible breach in security policy
    
    • System/process/people may (will) have vulnerabilities
    
    • Attackers have motivation and goals
    
    • Threat is an attacker exploiting a vulnerability
    
    • Identifying threats is a key part of security design
    
    • threats are where you focus your security effort
    
    • threat modelling is the key activity
    18
    Analyse
    

    View Slide

19. Threat Modelling
    A procedure for optimizing security by identifying
    objectives and vulnerabilities, and then defining
    countermeasures to prevent, or mitigate the effects
    of, threats to the system — OWASP
    
    • Identify the real risks to focus security effort
    
    • A technique all developers should be familiar with
    19
    Analyse
    

    View Slide

20. Threat Modelling
    • Who might attack your system?
    
    • What is their goal?
    
    • Which vulnerabilities might they exploit?
    20
    Alice
    Bob
    Eve
    Attacker: opportunist insider

    Goal: secret document

    Vulnerability: unprotected key
    Analyse
    

    View Slide

21. Finding Threats - STRIDE
    Spoofing Pretending to be someone that you’re not
    Tampering Changing information you shouldn’t
    Repudiation Being able to deny performing an action
    Information Disclosure Getting access to information illicitly
    Denial of Service Preventing a service being offered
    Elevation of Privilege Gaining privileges you shouldn’t have
    Analyse
    

    View Slide

22. Capture Threat Model
    Analyse
    ID 25 26
    Threat Type Tampering Spoofing
    Component WebUI WebUI
    Threat
    Javascript tampering in
    browser, altering order data
    WebUI user spoofing session
    ID for other user account
    Mitigation
    OPR-5543 - Add validation
    and unit tests for incoming
    order
    OPR-5547 - Regenerate
    session ID and recheck on
    every request
    

    View Slide

23. Exploring Attacks - The Attack Tree
    Attacker: Professional hacker

    Goal: Obtain customer credit card details

    Attack: Extract details from the system database.
    
    1. Access the database directly
    
    1.1. Crack/guess database passwords
    
    1.2. Crack/guess OS passwords to bypass db security
    
    1.3. Exploit a known vulnerability in the database software
    
    2. Access the details via a DBA
    
    2.1. Bribe a database administrator (DBA)
    
    2.2. Social engineering to trick DBA into revealing details
    
    3. …
    23
    Analyse
    

    View Slide

24. Comparing Threats - DREAD Model
    • Risk = Damage (1..10) + 

    Reproducibility (1..10) + 

    Exploitability (1..10) + 

    Affected Users (1..10) + 

    Discoverability (1..10)
    
    • Sum values and divide by 5 for the DREAD rating
    
    https://www.owasp.org/index.php/Threat_Risk_Modeling
    
    • Can be criticised for lack of consistency
    
    • Still a useful process - but sanity check results
    24
    Analyse
    

    View Slide

25. DREAD Model Example
    • Suppose a threat where …
    
    • damage limited to individual users => 5/10
    
    • is reproducible with a browser => 10/10
    
    • needs malware for the exploit => 5/10
    
    • affects many but not all users => 5/10
    
    • and can be discovered easily => 10/10
    
    • DREAD value = (5+10+5+5+10)/5 = 7/10
    
    a useful process … but thinking is still required!
    25
    Analyse
    

    View Slide

26. Libraries for Known Problems
    • OWASP Top 10 list
    
    • https://www.owasp.org/index.php/ 

    Category:OWASP_Top_Ten_Project
    
    • WASC threat classification
    
    • http://projects.webappsec.org/f/WASC-TC-v2_0.pdf
    
    • Mitre’s CAPEC & CWE
    
    • Common Attack Pattern Enumeration & Classification
    
    • Common Weaknesses Enumeration
    26
    Analyse
    

    View Slide

27. Security Abuse Cases
    User Logs In
    Search Catalogue
    Order Items
    Customer Attacker
    Steal Auth
    Token
    Spoof
    Authorisation
    «threatens»
    «threatens»
    «depends»
    Analyse
    

    View Slide

28. Abuse Case Example
    Abuse Case: Spoofing Authorisation via Valid Authentication
    Threat:
    The misuser steals an authorisation token and attempts to use it
    via a valid (other) authenticated identity
    Preconditions:
    1) The misuser has a valid means of user authentication

    (e.g. username/password).
    2) The misuser has a stolen user authorisation token.
    Actions:
    1. The system shall request the user’s identity and authentication.
    2. The misuser authenticates himself correctly.
    3. The system shall identify and authenticate the user.
    4. The misuser attempts to authorise using the stolen token.
    5. The system rejects the authorisation attempt, audits the event,
    terminates the session and locks the user account.
    Postconditions:
    1. The system shall have identified and authenticated the misuser
    2. The system shall have prevented the misuser from stealing
    another user’s means of authorisation.
    Analyse
    

    View Slide

29. Minimise the Attack Surface
    • The attack surface is the set of potentially
    vulnerable ways into the system (“attack vectors”)
    
    • smaller attack surface = less to attack and secure
    
    • OWASP definition:
    
    • all channels into and out of the system
    
    • the code securing those channels
    
    • data of value within the application (security & domain)
    
    • the code securing this data
    
    • Reduce interfaces, protocols, services, …
    
    • conflict with other goals!
    29
    Mitigate
    

    View Slide

30. Security Countermeasures
    • Once risks prioritised then implement mitigations
    
    • Some are well known and relatively straightforward
    
    • e.g. use of role based access control
    
    • Some are more complex but well known
    
    • e.g. XSS or SQL injection require input validation
    
    • Some need custom solutions
    
    • e.g. attacks based on organisation structure
    
    • Remember people, process and technology!
    30
    Mitigate
    

    View Slide

31. Incident Response
    • Despite security a system may breached
    
    • Need a plan for what you do when it happens
    
    • an incident response plan
    
    • a standing incident response team
    
    • Broader than technical mitigation
    
    • technical, management, legal & communications
    
    • A plan allowing a clear, logical, risk driven response
    
    • analysis, mitigation, evidence, communication, lessons
    
    • Practice your response
    31
    Mitigate
    

    View Slide

32. Secure Implementation
    • Secure design is useless if implemented insecurely
    
    • secure implementation outside the scope of this talk
    
    • Secure implementation can be complicated
    
    • requires knowledge and care
    
    • relatively specialist today
    
    • Static analysis and expert code review
    
    • FxCop, FindBugs, CodeAnalysis, Coverity, Fortify, …
    
    • OWASP code review guidelines
    
    • Oracle Java security guidelines
    32
    Mitigate
    

    View Slide

33. Top Application Security Coding Errors
    • Not thoroughly validating input
    
    • Injection attack vulnerabilities
    
    • Insecure randomness
    
    • Using custom cryptography
    
    • Insecure logging
    
    • Careless exception handling
    
    • Lack of security testing
    33
    … this topic needs another session
    Mitigate
    

    View Slide

34. Testing and Verification
    • As a software quality security needs to be tested
    
    • security testing largely outside the scope of this talk
    
    • Wide range of security validation activities:
    
    • static analysis of code
    
    • functional testing of security features
    
    • penetration / known vulnerability / fuzz testing
    
    • manual system security review
    
    • threat mitigation tests
    
    • Risk driven approach needed to maximise RoI
    
    • Consider third party assistance
    34
    Validate
    

    View Slide

35. Design Principles for Secure Systems
    35
    

    View Slide

36. Principle: Least Privilege
    • Common problem is broad privileges
    
    • Always limit to the essentials
    
    • what do people need to do their jobs
    
    • anything else is an exception
    
    • Mitigate malice, error and mischance
    
    • But allow people to get their jobs done
    
    • Example: don’t run services as “root” or “Administrator”
    36
    

    View Slide

37. Principle: Separate Responsibilities
    • Separate and compartmentalise

    responsibilities and privileges
    
    • better control and accountability
    
    • Limits the impacts of successful attacks
    
    • and makes attacks less attractive
    
    • Separate by subsystem, separate by functional role
    
    • Example: Payments admin has no control over orders
    37
    

    View Slide

38. Principle: Simplest Solution Possible
    • Security => understanding the design
    
    • Allows analysis
    
    • Complex design unlikely to be understood
    
    • Avoid
    
    • complex failure modes
    
    • implicit behaviour
    
    • unnecessary features
    
    The price of reliability is the pursuit of the utmost simplicity -
    C.A.R. Hoare
    38
    

    View Slide

39. Principle: Audit Sensitive Events
    • Record all significant security events
    
    • An audit log acts as:
    
    • a record of activity
    
    • a deterrent to wrong doing
    
    • a log to reconstruct the past
    
    • a monitoring point
    
    • Remember security for the audit log in the policy and
    implementation
    
    • don’t allow “super users” to alter the audit log
    39
    

    View Slide

40. Principle: Use Secure Defaults and Fail Securely
    • Default settings usually not changed!
    
    • disabling security must be a decision
    
    • Example:
    
    • default network connections on a secure transport
    
    • Make sure that failure modes end up in a secure state
    
    • Example: don’t suspend auditing if the log fills up
    
    (Conflicts with properties like scalability and availability)
    40
    

    View Slide

41. Principle: Be Careful Who You Trust
    • Assume that unknown entities are 

    untrusted
    
    • have a clear process to establish trust
    
    • don’t assume who is connecting
    
    • Be careful of intermediate entities
    
    • man-in-the-middle attacks
    
    • ensure end-to-end security
    
    • Don’t blindly trust 3rd party components
    
    • check signatures on code, use trusted sources
    41
    

    View Slide

42. Principle: Never Rely Upon Obscurity
    • Hiding secrets is difficult
    
    • someone is going to find them
    
    • accidentally it not on purpose
    
    • susceptible to “fuzz” attacks
    
    • People do figure things out
    
    • many attackers have a lot of time
    
    • they have to be lucky once
    
    • Assume attacker with perfect knowledge
    
    • this forces secure system design
    42
    

    View Slide

43. Principle: Defence in Depth
    • Don’t rely on one level of security
    
    • secure every level in your application
    
    • failures at one level stopped at the next
    
    • Example: secure your services and your database
    43
    Level 1: service Level 2: database Level 3: table
    Level 4: encrypt
    

    View Slide

44. Summary - Design Principles for Secure Systems
    • Principles to guide system design:
    
    • Assign the least privilege possible
    
    • Separate responsibilities
    
    • Use the simplest solution possible
    
    • Audit sensitive events
    
    • Fail securely & use secure defaults
    
    • Be careful who you trust
    
    • Never rely upon obscurity
    
    • Implement defence in depth
    
    • Find the weakest link
    44
    

    View Slide

45. Summary
    45
    

    View Slide

46. Summary
    • We’ve looked how to improve system security
    
    • we need to be risk and principle driven
    
    • Security requires: People, Process and Technology
    
    • the weakest of the three is your security level
    
    • Security needs to be designed in
    
    • its very difficult and expensive to add later
    
    • Be guided by risks not security technologies
    
    • threat risk models (STRIDE and DREAD); attack trees
    
    • Get the experts involved for significant risks
    
    • and never invent your own security technology!
    46
    

    View Slide

47. Summary (ii)
    Never stop asking “why?” and “what if?”
    
    critically important info sec questions!
    47
    

    View Slide

48. Resources
    • OWASP - http://www.owasp.org
    
    • Top 10, cookbooks, guides, sample apps, tutorials, …
    
    • Microsoft SDL - http://www.microsoft.com/security/sdl
    
    • complete security development lifecycle with resources
    
    • Elevation of Privilege game- http://tinyurl.com/eopgame
    
    • card game which helps to explain and drive threat modelling
    
    • Trike - http://www.octotrike.org
    
    • alternative threat modelling approach
    
    • CAPEC, CWE - http://{capec,cwe}.mitre.org
    
    • threat and vulnerability lists
    48
    

    View Slide

49. Resources
    • CPNI - http://www.cpni.gov.uk
    
    • UK government support for cyber security
    
    • US Government CERT - https://www.us-cert.gov
    
    • CMU’s CERT - http://cert.org
    
    • vulnerability monitoring and alerting
    
    • WASC - http://www.webappsec.org
    
    • similar organisation to OWASP
    
    • SANS Institute - http://www.sans.org
    
    • security research and education
    49
    

    View Slide

50. Books
    

    View Slide

51. Eoin Woods
    
    eoin.woods@endava.com

    www.eoinwoods.info

    @eoinwoodz
    Questions?
    

    View Slide

52. Appendix: Overview of Security
    Mechanisms
    52
    

    View Slide

53. Security Mechanisms and Attacks
    • This talk is for system designers, not security
    specialists
    
    • Understanding mechanisms and attacks is hard
    
    • people who like this sort of thing are security
    engineers!
    
    • This section overviews key mechanisms and some
    of the more important types of attack
    
    • this isn’t a detailed explanation of any of this
    
    • make sure you consult a security expert when needed
    
    • this is useful to understand the basics and the
    53
    

    View Slide

54. Partial Summary of Security Mechanisms
    Authentication

    (“Who are you?)
    Usernames & passwords, 2FA,
    biometrics, certificates, …
    Authorisation
    (“What can you do?”)
    Roles, access control lists, OAuth,
    permissions, …
    Confidentiality

    (“Keeping stuff secret”)
    Encryption, access control lists, …
    Integrity

    (“Stop tampering”)
    Cryptographic hashing, checksums, …
    Non-Repudiation

    (“You did that”)
    Cryptographic signing, audit trails, …
    Auditing

    (“What happened, when?”)
    Secure record of who did what, when
    

    View Slide

55. Cryptography and its Uses
    • Cryptography: the process of keeping information
    private (typically) using a cypher and a key
    
    • Two broad subfields:
    
    • Symmetric Key - the same key to encrypt and decrypt
    
    • Public Key - a pair of keys one to encrypt one to
    decrypt
    
    • Often used together for real applications
    
    • Applications of cryptography: privacy (encryption),
    integrity (signing) and non-repudiation (signing)
    
    • Difficulties with cryptography include designing
    55
    

    View Slide

56. Basic Symmetric Key Cryptography
    Alice Bob
    Encrypt Decrypt
    

    View Slide

57. Basic Public Key Cryptography
    Alice Bob
    Bob’s public key
    Encrypt
    Bob’s

    private 

    key
    Decrypt
    Bob’s keypair
    

    View Slide

58. Comparing Symmetric and Public Key
    58
    Symmetric Key Public Key
    Single shared key
    A keypair needs to be generated with
    public and private key
    Single key needs to be shared
    securely
    Private key is kept secret, public key
    can be freely shared
    Efficient computationally Really slow (~100s times slower)
    Classic attack is stealing keys
    Classic attack is forging public keys,
    so faking identity
    Big challenge is passing keys around
    Big challenge is chains of trust so
    you know keys (certs) are valid
    

    View Slide

59. Example of Crypto in Practice: Key Exchange
    Client Server
    Client Hello

    (“Hello - here are the options I know about ….”)
    Server Hello

    (“OK - here are the options we’ll use ….”)
    Server Certificate

    (“Here is my certificate (public key) ….”)
    Client Key Exchange

    (“Here is a symmetric key” encrypted with server public key)
    Data Exchange

    (encrypted with symmetric key)
    

    View Slide

60. Hashing and Signing
    Alice
    Bob
    Hashing
    private key
    keypair
    hash
    Signing
    Verification
    public key
    

    View Slide

61. Summary of Common Attacks
    Social Engineering

    (Attack the people)
    Bluffing, bribery, coercion, …
    Network Attacks
    (Protocol exploits)
    SYN floods, DDoS, DNS attacks, …
    Application Attacks

    (Flaws and bugs)
    XSS, SQL injection, corrupted input
    (fuzz), DLL attacks, CGI/SSI attacks …
    Programming Attacks

    (Abuse of a language)
    Stack overflows, buffer overflows,
    known bugs in libraries, …
    Crypto Attacks

    (Algorithms or design)
    Known plain/cipher text, randomness,
    cert forgery, man in the middle, traffic
    analysis…
    

    View Slide