Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

What Every Developer And Tester Should Know About Software Security

253 views

Published on

Software security is best built in. This presentation introduces three essential things to help you design more secure software. In order to have a secure foundation, you can create and select security requirements for your applications using evil user stories and utilizing existing material for example from OWASP.

Another useful skill is threat modeling which helps you to assess security already in the design phase. Threat modeling helps you deliver better software, prioritize your preventive security measures, and focus penetration testing to the most risky parts of the system. The presentation covers various methods, such as the STRIDE model, for finding security and privacy threats.

You will also learn what kind of security related testing you can do without having any infosec background.

Published in: Software
  • Be the first to comment

What Every Developer And Tester Should Know About Software Security

  1. 1. What Every Developer And Tester Should Know About Software Security Anne Oikarinen @Anne_Oikarinen Senior Security Consultant Nixu Corporation
  2. 2. whoami → Interested in computers, astronomy, physics, how stuff works → studied infosec & telecommunications → software testing → network security testing / test management / training instructor / network design / software development → incident response & security awareness → hacker / guiding dev teams how to build security in Anne Oikarinen Now Senior Security Consultant @ Nixu Corporation, Finland M.Sc. (Tech), CISSP, GMOB Twitter: @Anne_Oikarinen My weird path to #infosec
  3. 3. Why do we need software security?
  4. 4. Why do we need software security?
  5. 5. Building security in Threat modeling Incident response Penetration testing Security requirements Where people usually focus on What you should start with
  6. 6. Building security in Automated code review Anomaly detection Checking known vulnerabilities Dynamic testing Automated error-free deployment Performance testing Open source license compatibility Threat modeling Deep code review Finding logic flaws Incident response Penetration testing Fuzzing Automated security tests Security requirements Where people usually focus on What you should start with
  7. 7. Security audit does not look like this. Security people don’t want to embarrass you or annoy you. They want to find vulnerabilities before evil people do.
  8. 8. Security requirements Security testing Threat modeling Key elements of secure software Assets to protect Evil user stories Attack surface Security standards
  9. 9. Security requirements Security testing Threat modeling Security requirements Assets to protect Evil user stories Attack surface Security standardsHow to create and select requirements that are useful to you
  10. 10. ”How can you protect something if you don’t know it exist or its value?”
  11. 11. Evil user stories An attacker should not be able to purchase items without paying An attacker should not be able to hack the site using known vulnerabilities A user should not be able to see another user’s personal information A user should not be able to send spam on the contact form Many simultaneous users should not be able to crash the website The admin should not be able to accidentally shut down the server An attacker should not be able to…
  12. 12. Put evil user stories to backlog Evil user story • A user should not be able to send spam on the contact form Investigate mitigations • Captcha • Rate limiting • Input validation Backlog item • Acceptance criteria: • Rate limiting • Input validation • Security testing Mitigations as acceptance criteria
  13. 13. Don’t reinvent the wheel
  14. 14. Security standards and best practices Web applications • OWASP Application Security Verification Standard (ASVS) • OWASP top 10 Mobile applications • OWASP Mobile Application Security Verification Standard (MASVS) Internet of Things • OWASP top 10 for IoT • Code of practice for consumer IoT security (UK Gov) Something else? • Cherry-pick relevant parts from ASVS Use existing material to select security requirements
  15. 15. Security requirements Security testing Threat modeling Threat modeling Assets to protect Evil user stories Attack surface Security standardsWhat could go wrong? What can we do about it?
  16. 16. Finding weaknesses in the design phase Targeting pentesting based on risk Testing does not find all weaknesses Benefits of threat modeling
  17. 17. What threats are relevant to our business? Scriptkiddie • DDoS for the lulz • Mitigation: Load balancer CyberCriminal • Ransomware target search from Shodan • Mitigation: Updates RPAmisconfig • Configuration errors and mistakes • Mitigation: Automatic testing
  18. 18. Threat workshop • Threat modeling • Attack surfaceSprint 1 Sprint 2 • Check threat model • Residual riskSprint n Who, when, and what? Bugs Test cases Backlog Documents Testers Developers Product Owner Infosec Specialist
  19. 19. Attack tree visualizes threat scenarios Vulnerability in server components Web site delivers malware Web server compromised Drop in share price Loss of reputation Password guessed User information gets stolen
  20. 20. Threat modeling techniques How to find threats from the features and architecture
  21. 21. Analyzing use cases and user stories 9.2.201922 Dangerous or permissive features • Viewing all users • Uploading files • Viewing health records Admin interfaces • Modifying users • Deleting all files • Starting and stopping services Dangerous combinations of user roles • Can both request and approve Who can access? Access control bypass? Need for multi- factor authentication? Traceability?
  22. 22. STRIDE model for architecture and data flow analysis (S) Spoofing (T) Tampering (R) Repudiation (I) Information Disclosure (D) Denial of Service (E) Elevation of Privilege Database Web server Browser Mobile app DB management Log management Log server
  23. 23. Interesting Feature Archi- tecture Data Flow Analysis
  24. 24. User buys a book from an online book store Database Web server Browser DB management Log server • Is the user authenticated? • Can you spoof someone else? • Can you bypass access control? • Is the traffic encrypted? • Can you try to inject evil stuff? • Can you buy a book without actually paying? • DoS or DDoS? • Is there mutual authentication between servers? • Can you get a listing of which books everyone bought? • Can you inject evil stuff? • What if DB connection is lost? • Can an evil shopkeeper tamper with the database and modify the delivery address? • Does it leave a log entry? Log management • Do the operations of users/admins leave a log entry? • Do logs contain personally identifiable data? • Does someone monitor the logs?
  25. 25. Identifying attack surface Database Web server Browser Mobile app DB management Log management Log server API server Logistics company delivery appUser interfaces Integrations to other systems APIs
  26. 26. Threats in development and operations
  27. 27. Threat modeling a software development process Package sources and integrity? Detecting and updating known vulnerabilities? Detecting code quality issues? Storing credentials securely? Securing access to source code and CI? Testing environments and test data? Security testing Manual steps in deployment? Following procedure ALWAYS? Logging and monitoring?
  28. 28. Privacy threats 101
  29. 29. Check at least these things about privacy Logs Personal data in logs? Who has access to the logs? Tracking access to personal data? Test data Copy from production? Level of test environment’s security? Who has access? Scrambled data Can it be reversed? Ask a privacy expert if unsure
  30. 30. Finding weaknesses in the design phase Targeting pentesting based on risk Testing does not find all weaknesses Benefits of threat modeling
  31. 31. NOW WHAT?
  32. 32. Do your own security testing Security requirements Security testing Threat modeling Assets to protect Evil user stories Attack surface Security standards
  33. 33. The attacker won’t bother picking locks if they can climb over the fence. Pick the low-hanging fruit Don’t overlook low-level security findings
  34. 34. You can improve security, too! Dependency tracking • Known vulnerabilities in open source libraries • Open source alternative: OWASP Dependency check • Commercial tools can detect incompatible licenses Code quality checks • Detecting security bugs from source code • Open source alternative: OWASP SonarQube • Note: Does not replace security-oriented code review! Scan your repositories
  35. 35. You can improve security, too! Application testing • OWASP ZAP: scanning web application vulnerabilities, can be automated • Burp Suite (Community Edition, Professional, Enterprise): hacker’s choice manual security testing, Enterprise has CI integration • SQL injection testing with sqlmap Network level testing • Lack of security headers, insecure TLS settings – testssl.sh • Open ports, network segmentation – nmap Test your applications and automate
  36. 36. Security in every step Automated code review Anomaly detection Checking known vulnerabilities Dynamic testing Automated error-free deployment Performance testing Open source license compatibility Threat modeling Deep code review Finding logic flaws Incident response Penetration testing Fuzzing Automated security tests Security requirements
  37. 37. Anne Oikarinen Senior Security Consultant anne.oikarinen@nixu.com @Anne_Oikarinen @nixutigerteam nixu.com

×