This document discusses common problems with how application security is implemented. It argues that software developers often lack security knowledge and focus on functionality over security. Security teams also lack development experience and focus on compliance over practical security. As a result, security is treated as an afterthought through ineffective practices like sole reliance on penetration testing. The document recommends a proper Secure Development Lifecycle approach involving security training, secure coding practices, testing and ongoing improvements.

1. bitter truth
about
software security
Vlad Styran
OSCP CISSP CISA
Berezha Security

5. Disclaimers
Crappy science: no supporting
data or peer reviews
Based on my own (mostly
negative) experience
If you have rotten potatoes,
wait until the end

6. Agenda… sort of…
Application Security is done wrong. Period.
Questions are:
1. Who does it wrong?
2. What is done wrong?
3. How is it done wrong?

7. Who? Stake-holders:
Software people
• Have no idea about security
• Driven by functionality and deadlines
• Focused on visible features
Security people
• Have no idea about software development
• Driven by budgets, "risk” and compliance
• Focused on policy and best practice
Business people (we won’t touch those)

8. What? is wrong with
software people:
Don’t care about security by
default
Start hiring appsec folks “into
projects” once clients start to
ask questions
Rarely create “horizontal
practices” for ad-hoc security
assessments

9. What? is wrong
with software
people:
Too much into their
own stuff
Usually very isolated
cultures
Don’t bother about
appsec until they get
hacked

10. What? is wrong with
software people:
Don’t care about security at all
Have zero initial budget
Are forced into appsec by market
regulations or investors
Are forced into appsec as a part of
general corporate BS once they
end being startups

11. What? is wrong with
software people:
Don’t see appsec as a feature
(because it’s invisible)
Think their code is secure by default
and maybe has a few vulnerabilities
to be “tested” or “scanned” before
release
Think their developers are well
educated in appsec because they
follow some weirdos on Twitter and
Facebook

12. What? is wrong with
security people:
Have mainly network, infrastructure,
intelligence/law enforcement background
Are focused on setting the rules (“paper
tigers”) and deploying controls (“blinking
boxes”)
As much as the software folks, believe in
that ”pentest” or “code review” will solve
all their problems
The followers of the Best Practice Church

13. How? is the appsec done wrong:
Pentest as a first step in a security
program
Pentest as the only appsec exercise
before the product goes live
No initial budget as a way to cut
costs
No developers awareness training
before the project starts
Treating appsec as a dull routine that
has to be automated

14. How?
Pentestas a firstortheonlypartof securityprogram
Pentest is a measurement tool for
the effectiveness of your security
program
If there is nothing yet to measure, it
makes no sense
• Some hackers will come
• They will report a bunch of bugs
• These won’t be all the bugs
• These won’t be the worst bugs
• These will be the easiest to find
• This will affect your release date

15. How?
No initial budget as a way to cut costs
Built-in vs Bolt-on security
Startups don’t care
(Until it’s too late)
Thinking of security as a project,
process, business function etc.
Not getting an intuition of risk
(Not knowing how much it actually costs)
The job market is hell
(Or heaven, depends on your POV)

16. How?
No developers training
When Lemon Markets, Imposter Syndrome & Dunning–Kruger collide - Haroon Meer
https://www.youtube.com/watch?v=YCijTioaCDw

17. How?
Urge for automated security scanning

18. How?
Urge for automated security scanning
DAST (Security Scanner)
Knows nothing about your code
Gets mostly input/output flaws
Covers about 15% of bugs
Requires a consultant to get more
Costs less than SAST
SAST (Source Code Analyzer)
Knows everything about your
code (but gets nothing)
Gets only semantic and
implementation-level flaws:
business logic is way out of scope
Covers about 274% of bugs (out of
1078% possible)
Costs 10x–100x more than DAST

19. Let’s summarize
Developers and QAs who have no
appsec background or training
Are supposed to write secure code
That contains only few security bugs
All of which will be found by a
security scanner or a code analyzer
For free

20. Thank god, there are hackers!
Expectations
1. Come to an ethical hacker 2
weeks before the release
2. Ask for a DAST for about $2-3k
3. Expect a clean & green report
4. Put it on the wall and go live
5. Live happy ever after
Reality
1. Get shocked DAST takes at
least 3 to 4 weeks
2. And costs much more
3. Get 10 critical bugs during first
week and 50+ pages report
4. Fix the bugs for 2 months
5. Cry over the retest report and
realize you still have bugs

21. Thank god, there are hackers!
How hackers changed the security industry - Chris Wysopal
https://www.youtube.com/watch?v=LSH3CyR35x4

22. https://www.microsoft.com/en-us/sdl/default.aspx

23. What is SDL?
A bunch of practices that improve “software
assurance” level (a fancy name for appsec)
Security architecture and design
Formulating security requirements
Secure coding and code review
Security testing/pentesting
Secure deployment and operation
Incident response and security patches
Automating all of the above
And many many more

24. How to SDL?
1. Give the team an appsec awareness training
2. Consult an SDL framework and choose practices you can implement
3. Plan for adding practices that you should implement
4. Hire a security pro or consultant to help you with practices you
cannot implement by yourself
5. Undergo an external appsec assessment after the first full SDL cycle
and at least before every major release
6. Undergo an external SDL assessment/audit regularly and improve
using the results

25. Who should SDL?
Developers, Testers, DevOps – to
relevant extent
Security “Champions” or
“Evangelists” – part time
Project Managers – at higher level
Architect and Leads – deep dive
AppSec Analysts – full time

26. Good practice
https://www.owasp.org/ http://owasp.kyiv.ua/

27. Notable OWASP projects
OWASP Top Ten
OWASP Testing
OWASP SAMM
OWASP ASVS
OWASP ZAP
OWASP Juice Shop

29. SAMM practices example

30. Cheat codes: roadmap templates

31. How to get in?
OWASP Kyiv https://owasp.kyiv.ua
AppSec Awareness Training notes
https://github.com/sapran/appsec_a
wareness_training
Awesome AppSec curated list
https://github.com/paragonie/aweso
me-appsec
AppSec Course on Coursera
https://www.coursera.org/learn/soft
ware-security
WAHH book
Ross Anderson’s Security Engineering
book

32. How to find me
sapran@pm.me
https://fb.me/vstyran
@arunninghacker