# Dev Training ### Intro <!-- .slide: class="title-slide" --> ## Why do security incidents occur? ## Assumptions Notes: False assumptions sink ships ### Assumptions I assumed... * this library was safe * this function call was safe * this repo was private * that no one could access that data * this was configured safely * this input was safe * etc Notes: We all make assumptions all the time. They are often wrong. Almost all of them are wrong some of the time. ### Assumptions ```python >>> ch = '?' >>> print(ch.lower() == ch.upper().lower()) >>> print(ch.upper() == ch.lower().upper()) ``` ```python True True ``` <!-- .element: class="fragment" data-fragment-index="1" --> Notes: Any Python wizards in the house? What is the output here? What is a lower- or upper-case question mark? Does this even make sense? True True. ### Assumptions ```python >>> ch = 'ß' >>> print(ch.lower() == ch.upper().lower()) >>> print(ch.upper() == ch.lower().upper()) ``` ```python False True ``` <!-- .element: class="fragment" data-fragment-index="1" --> Notes: Sometimes it's not that clear-cut. How many people expected this behavior? ### Other reasons * Malicious insider * Incompetence * Social engineering Notes: You are all very smart. Many of you way smarter than Steinar or I. That is not enough. To beat the hackers, you must think like hackers. ## Overhead of security flaws Notes: "But security creates extra overhead!" I hear you thinking. We hear you and you are totally right. Let's take a look at how much overhead it creates for each stage of software development process. ### In design stages Low overhead * I'm going to use this library * I'm going to use this framework Notes: This is where you should start thinking about security. This is the cheapest and easiest time to prevent vulnerabilities. With some minor research on available frameworks and libraries, for example, you can prevent major headaches down the road. ### In development Low overhead * I'm going to use this library/function call * I'm going to sanitize this input * I'm going to isolate this process Notes: We can't forsee every issue during the design phase. We need to stay vigilant during development and make sure to take security into account when making on-the-fly decisions in development. ### In testing Relatively low overhead * Identify issue * Fix * Pull request and merge Notes: This is where security starts to get more expensive. Catching security bugs post-development is way better than not catching them at all, but it may mean delayed releases, refactoring work and so on. ### In production Very high overhead * Incident * All hands on deck * Frantic search for cause Notes: At this point, prevention has failed and a vulnerability may have become an incident. This will require a complex and expensive response that deserves its own section. ## Cost of incident in production ### Operational * Efforts are focused on * Identifying cause * Fixes * Assessing impact * Normal operations will be disrupted Notes: The operational costs include damage control and analysis. This often includes service downtime and other disruptions. ### Reputational * PR nightmare to manage * Customers and clients need to be notified * Authorities might need to be notified Notes: Managing reputational impact provides its own challenges. What do we tell employees, customers , the press, etc? What laws do we need to comply with? Which government agencies must be notified? ### Financial * Loss of business * If personal data is involved * Possible GDPR fines * Possible NIS fines Notes: How much does an incident cost? It is difficult to estimate the fallout of a security incident. Long-term effects may include loss of business, fines or permanent data loss. ## Security ### Can security be attained * Security is a journey, not a destination * It's always a game of cat and mouse * New systems/methods/protocols invite new issues and flaws Notes: How can we make sure this does not happen? Sadly, we can't. We are caught in a constant game of cat and mouse. We as developers need to catch and seal every possible way into our systems, but the hackers only need to find one. However, if we make sure to integrate security into every stage of product development and maintenance, we can greatly mitigate the risks. ## This training ### Coverage * Focus on web security * Mainly [OWASP Top 10 vulnerabilities](https://owasp.org/Top10/) Notes: We will be focusing on web security. The OWASP top 10 list is an excellent resource for the most prevalent issues to look out for. ### How * Introduce classes of common vulnerabilities * Present guidelines to avoid these vulnerabilities * Interactive exercises Notes: We will go through some of the most common vulnerability classes out there, discuss prevention and mitigation strategies and learn to think about our code from a hacker's point of view. For this purpose we have prepared intentionally vulnerable systems for you to exploit. ### Why * Web security * Most organizations' largest attack surface * Exercises * I hear and I forget. I see and I remember. I do and I understand. * Offensive * Develop the attacker's mindset * Make security a part of the development process Notes: Web applications are the primary attack surface in most cases. We believe that learning by doing is a great supplement to boring lectures. In order to keep out the hackers, we must think like hackers. We strongly believe that the best way to do that is to become hackers ourselves. ### It is not * Introduction to tooling for CI/CD pipeline * Too technology stack specific * Can be useful, but miss a lot * The solution to all your problems * That's drugs Notes: We will not be discussing CI/CD mitications in this training course. It is up to you to familiarize yourselves with solutions that are right for you and your products. Even a brief overview of available solutions would comprise at least one university course. ## Is this necessary? ### Highlights from last and this year * [Brimborg (2023)](https://www.brimborg.is/is/moya/news/netaras-a-kerfi-brimborgar) * [Rapyd (2023)](https://www.visir.is/g/20232490342d/greidslukortagatt-rapyd-liggur-nidri-vegna-netarasar) * [Penninn (2023)](https://www.visir.is/g/20232486195d/lokad-i-verslunum-pennans-vegna-netarasar) * [island.is phishing (2023)](https://cert.is/frettir-og-tilkynningar/frettasafn/frett/Fr%C3%A9ttir/cert-is-varar-vid-svikum-sem-bidja-vidkomandi-ad-tilgreina-vidskiptabanka152701) * [Attack on Árvakur (2024)](https://www.mbl.is/frettir/innlent/2024/06/24/storfelld_aras_a_arvakur_gogn_i_gislingu/) Notes: In case anyone doubts the necessity of improving security in development, here are some noteable examples of security breaches from last and this year. ### An oldie but goodie [Stack Overflow (2019)](https://stackoverflow.blog/2021/01/25/a-deeper-dive-into-our-may-2019-security-incident/) <img src="so.png"> Notes: Let's try to make sure nothing like this happens to us. ## Schedule ### Session 1 * Learn about Burp * Security vulnerabilities in general * Access control Notes: The agenda for today is to learn the basics of Burp Suite, a fantastic tool for web security assessments, gain general knowledge about security vulnerabilities and discuss the basics of access control. ### Session 2 * Focus on browser-based vulnerabilities * XSS * CSRF * Open redirect * SSRF Notes: In the second half, Steinar will cover these four browser-based vulnerability classes, how to identify, exploit and remediate them. ### Session 3 * Focus on injection vulnerabilities * SQL injection * Path injection * Command injection Notes: Tomorrow, we will take a look at so-called injection vulnerabilities, which allow hackers to cause software to misbehave by providing unexpected and malicious input. ### Session 4 * Various vulnerabilities and subjects * XXE * Authentication * Logging * Deserialization Notes: Finally, Steinar will cover these vulnerabilities to round out our knowledge of the most common software vulnerabilities.