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

3. Why
do we need
software
security?

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

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

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

14. Don’t reinvent the wheel

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

16. 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?

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

24. Interesting
Feature
Archi-
tecture
Data Flow
Analysis

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?

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

27. Threats in development
and operations

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?

29. Privacy threats 101

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

32. NOW WHAT?

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