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

System Security Beyond the Libraries

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.

Eoin Woods

June 20, 2016

More Decks by Eoin Woods

Other Decks in Programming


  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. Security Policy Clients Orders Refunds
 <= £100 Refunds
 > £100

    Onshore Service Agents Create, View,
 (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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. Exploring Attacks - The Attack Tree Attacker: Professional hacker

    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
  19. 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
  20. 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
  21. Libraries for Known Problems • OWASP Top 10 list •

 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
  22. Security Abuse Cases User Logs In Search Catalogue Order Items

    Customer Attacker Steal Auth Token Spoof Authorisation «threatens» «threatens» «depends» Analyse
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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
  34. 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
  35. 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
  36. 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
  37. 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
  38. 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
  39. 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
  40. 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
  41. 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
  42. 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
  43. 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
  44. 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
  45. Basic Public Key Cryptography Alice Bob Bob’s public key Encrypt

 key Decrypt Bob’s keypair
  46. 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
  47. Example of Crypto in Practice: Key Exchange Client Server Client

 (“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)
  48. 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…