SlideShare a Scribd company logo

What Every Developer And Tester Should Know About Software Security

•
•
A
Anne Oikarinen

The document discusses what software developers and testers should know about software security. It emphasizes the importance of threat modeling to understand potential threats, creating security requirements, and including security testing in the development process. It provides examples of security best practices like checking for vulnerabilities, conducting code reviews, and penetration testing applications to find issues before attackers. The goal is to integrate security practices into development rather than as an afterthought.

1 of 38
Downloaded 22 times
What Every Developer And Tester Should Know About Software Security Anne Oikarinen @Anne_Oikarinen Senior Security Consultant Nixu Corporation
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
Why do we need software security?
What Every Developer And Tester Should Know About Software Security
Why do we need software security?
Building security in Threat modeling Incident response Penetration testing Security requirements Where people usually focus on What you should start with
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
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.
Security requirements Security testing Threat modeling Key elements of secure software Assets to protect Evil user stories Attack surface Security standards
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
”How can you protect something if you don’t know it exist or its value?”
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…
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
Don’t reinvent the wheel
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
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?
Finding weaknesses in the design phase Targeting pentesting based on risk Testing does not find all weaknesses Benefits of threat modeling
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
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
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
Threat modeling techniques How to find threats from the features and architecture
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?
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
Interesting Feature Archi- tecture Data Flow Analysis
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?
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
Threats in development and operations
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?
Privacy threats 101
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
Finding weaknesses in the design phase Targeting pentesting based on risk Testing does not find all weaknesses Benefits of threat modeling
NOW WHAT?
Do your own security testing Security requirements Security testing Threat modeling Assets to protect Evil user stories Attack surface Security standards
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
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
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
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
Anne Oikarinen Senior Security Consultant anne.oikarinen@nixu.com @Anne_Oikarinen @nixutigerteam nixu.com

More Related Content

What Every Developer And Tester Should Know About Software Security

  • 1. What Every Developer And Tester Should Know About Software Security Anne Oikarinen @Anne_Oikarinen Senior Security Consultant Nixu Corporation
  • 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
  • 5. Why do we need software security?
  • 6. Building security in Threat modeling Incident response Penetration testing Security requirements Where people usually focus on What you should start with
  • 7. 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
  • 8. 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.
  • 9. Security requirements Security testing Threat modeling Key elements of secure software Assets to protect Evil user stories Attack surface Security standards
  • 11. ”How can you protect something if you don’t know it exist or its value?”
  • 12. 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…
  • 13. 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
  • 15. 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
  • 17. Finding weaknesses in the design phase Targeting pentesting based on risk Testing does not find all weaknesses Benefits of threat modeling
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. Threat modeling techniques How to find threats from the features and architecture
  • 22. 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?
  • 23. 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
  • 25. 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?
  • 28. 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?
  • 30. 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
  • 31. Finding weaknesses in the design phase Targeting pentesting based on risk Testing does not find all weaknesses Benefits of threat modeling
  • 33. Do your own security testing Security requirements Security testing Threat modeling Assets to protect Evil user stories Attack surface Security standards
  • 34. 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
  • 35. 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
  • 36. 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
  • 37. 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
  • 38. Anne Oikarinen Senior Security Consultant anne.oikarinen@nixu.com @Anne_Oikarinen @nixutigerteam nixu.com
  翻译：