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.

1. Security Beyond the Libraries
Eoin Woods
Endava
eoin.woods@endava.com / @eoinwoodz

2. Introduction
2

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

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

5. Introducing Security
5

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

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

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

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

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

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

12. Securing Systems
12

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

35. Summary
35

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

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

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

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

40. Books

41. Eoin Woods
eoin.woods@endava.com
www.eoinwoods.info
@eoinwoodz
Questions?

42. Appendix: Overview of Security
Mechanisms
42

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

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

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

46. Basic Symmetric Key Cryptography
Alice Bob
Encrypt Decrypt

47. Basic Public Key Cryptography
Alice Bob
Bob’s public key
Encrypt
Bob’s
private
key
Decrypt
Bob’s keypair

48. Comparing Symmetric and Public Key
48
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

49. 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)

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

51. 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…