Stay safe, grab a drink and join us virtually for our upcoming "Reveal the Security Risks in the Software Development Lifecycle" Meetup to learn how to find application security threats, issues in software development life cycle, build mature application security incident response processes and implement application security posture management.
Agenda:
17:00 - 17:05 - 'Opening words' - by Gary Berman (Cyber Heroes Network)
17:05 - 17:35 - 'Why securing the SDLC fails at scale' - by Liav Caspi (Co-Founder & CTO at Legit Security)
17:35 - 18:05 - 'The Real AppSec Issues' - by Josh Grossman (CTO at BounceSecurity)
18:05 - 18:35 - 'Application security and IR process' - by Vitaly Davidoff (Application Security Lead at JFrog)
18:35 - 19:00 - 'The ASPM way - a new approach' - by Liav Caspi (Co-Founder & CTO at Legit Security)
8. 8
Confidential and
What is a secure software-development-lifecycle?
Building secure software, making secure changes
Securing the software factory
Identifying and fixing security issues effectively
9. 9
Confidential and
The way software is assembled, built and deployed is complex.
Introducing – a simple pipeline
A single code
change:
No
review
required
Server
misconfigure
d
This is a “Highway to the Cloud”
AppSec Control Plane
10. 10
Confidential and
The way software is assembled, built and deployed is complex.
Introducing – the Pipeline
A single code
change:
Vulnerable
Open
Source
SBOM
required
11. 11
Confidential and
1. The way software is assembled, built and deployed is complex.
2. Introducing – the Pipeline
A single code
change:
Deployment
Misconfigurations
12. 12
Confidential and
The way software is assembled, built and deployed is complex.
Introducing – the Pipeline Vulnerable Plugin
accessible to
cloud admin key
13. 13
Confidential and
The way software is assembled, built and deployed is complex.
Introducing – the Pipeline
Base image
contains
vulnerabilities
Artifact storage
has weak
access controls
Unprotected
APIs
16. A deleted secret is an honest mistake.
It won’t come up in code review
It might stay in Git history forever (until
found)…
Example #1 – Secrets in code
18. Example #2 – GitHub Actions pawned
1. Developer creates a pull request
2. Automated tests are triggered before any human
reviews the code
3. Automated tests contain a flaw that allows the
changes to run custom command in a privileged
pipeline context
4. Attacker can use the context to steal credentials,
make any change to the GitHub org and clean up the
change request
Further read
How many are aware to how to
write a safe pipeline script?
Third party actions may make the
org vulnerable regardless..
19. Example #3 – Secure your artifacts
30%
of internet facing private
artifact registries expose a
high and above CVE
9%
Expose secrets and internal
technical data
22. Josh Grossman
■ Over 15 years of IT and Application
Security, IT Risk and development
experience
■ CTO for Bounce Security, value-
driven Application Security support
■ Consulting and training for clients
internationally and locally
■ Contact:
– @JoshCGrossman
– josh@bouncesecurity.com
– https://joshcgrossman.com/
– https://github.com/tghosth
■ OWASP Israel Chapter Board
■ Co-leader of the OWASP ASVS
Project
■ Major Contributor to the OWASP
Top Ten Proactive Controls project
■ Contributor to:
– OWASP Top 10 Risks
– OWASP JuiceShop
22
The Real AppSec Issues
@JoshCGrossman
23. AppSec in real breaches
The Real AppSec Issues
@JoshCGrossman 23
Verizon 2023 Data Breach Investigations Report
https://verizon.com/dbir/
24. The Real AppSec Issues
@JoshCGrossman 24
---[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 08 of 12
25. The Real AppSec Issues
@JoshCGrossman 25
https://owasp.org/Top10/
27. The real issues
■ Not your standard OWASP top 10
– A different “top 10”
■ Observed from real organizations and people
■ Food for thought
27
The Real AppSec Issues
@JoshCGrossman
28. The real issues
■ Not your standard OWASP top 10
– A different “top 10 6” (6 issues is enough!)
■ Observed from real organizations and people
■ Food for thought
28
The Real AppSec Issues
@JoshCGrossman
30. 1) Security is the developer’s job?
■ Not taught University, boot camps, online
tutorials.
■ Rarely incentivized or measured on this
■ Performance, UX, etc, are at least 2nd class
citizens...
– ...security usually isn’t.
■ Can’t secure from the sidelines
30
The Real AppSec Issues
@JoshCGrossman
31. 1) Security is the developer’s job?
My advice:
■ Security = a software characteristic
■ Need buy-in from R&D management – “Shift up”*
■ Interactive/interesting training
■ Security champions program
– Starting?
– Sustaining?
31
The Real AppSec Issues
@JoshCGrossman
* Heard this from Francesco Cipollone
@FrankSEC42
33. 2) What is OWASP?
■ Many developers are not familiar
■ OWASP can bring:
– Comprehensive requirements for security
– Networking and knowledge sharing
– Interactive developer training (members)
33
The Real AppSec Issues
@JoshCGrossman
34. 2) What is OWASP?
■ Questions:
– Can you name an OWASP project (not the top
10?)
– Have you been to an OWASP
meetup/conference?
34
The Real AppSec Issues
@JoshCGrossman
35. 2) What is OWASP?
■ Questions:
– Can you name an OWASP project (not the top
10?)
– Have you been to an OWASP
meetup/conference?
– Who has devs who go to OWASP meetups or
conferences? (more important)
35
The Real AppSec Issues
@JoshCGrossman
36. ■ Encourage R&D to be involved
■ Avoid “reinventing the wheel”
■ Build familiarity and find what works for them
– Tools like ZAP, Dependency-(Track|Check)
– Documents like ASVS, Cheat sheets
– Get involved in the Slack channel
36
The Real AppSec Issues
@JoshCGrossman
2) What is OWASP?
My advice:
37. 3) Tool fatigue
■ Software security = SAST/DAST/SCA/etc?
37
The Real AppSec Issues
@JoshCGrossman
40. ■ Cannot really be summarized in 3 bullets…
– Tools should support a goal
– Get clear management buy-in
– Gradual approach to findings (expectations)
■ Get the benefit by treating as a process
40
The Real AppSec Issues
@JoshCGrossman
3) Tool Fatigue
My advice:
42. 4) Pen testing is low value
■ Hard to judge quality of tester
■ Why are there:
– no findings?
– too many findings!
■ Findings not aimed at developers
■ Highlighted by Haroon Meer at 44CON
2012: “Penetration Testing Considered
Harmful” (Market for Lemons)
42
The Real AppSec Issues
@JoshCGrossman
43. 4) Pen testing is low value
My advice:
■ Get details of the tester's experience
■ See an example report
■ Testing based on a standard (e.g. ASVS)
■ Bug Bounty company better for high-risk issues?
– Specifically, as a penetration test!
https://appsecg.host/pentest
43
The Real AppSec Issues
@JoshCGrossman
44. 5) Integrating security early
■ "Shifting left" (should be "spread left")
■ Hard to create consistent process for:
– Security requirements
– Design security
– Threat modelling
■ Starting is easyish, continuing is hard
44
The Real AppSec Issues
@JoshCGrossman
45. 5) Integrating security early
My advice:
■ Consistent set of requirements
■ Customize based on feature characteristics
■ Tailored, developer led processes
■ Lightweight threat modelling
45
The Real AppSec Issues
@JoshCGrossman
46. 6) Security as project management
■ How much time spent on tasks requiring security
knowledge?
– Chasing metrics?
– Monitoring progress?
– Building project plans?
46
The Real AppSec Issues
@JoshCGrossman
47. 6) Security as project management
My advice:
■ R&D take responsibility for metrics
■ Security project manager / operations specialist
■ Make it to management clear where security
expert time is going
■ Security can focus on guiding and improving
47
The Real AppSec Issues
@JoshCGrossman
48. Summary of issues
1. Security is the developer’s job?
2. What is OWASP?
3. Tool fatigue
4. Pen testing is low value
5. Integrating security early
6. Security as project management
48
The Real AppSec Issues
@JoshCGrossman
49. Want to hear more?
49
The Real AppSec Issues
@JoshCGrossman
Building a High-Value AppSec Scanning
Programme
https://appsecg.host/lisreg
Accelerated AppSec – Hacking your Product Security
Programme for Velocity and Value (Virtual)
https://appsecg.host/bhreg
51. Key takeaways
■ Strategic and collaborative approach
■ Software security is software quality
■ Meet developers where they are
■ Tools should support a wider process
51
The Real AppSec Issues
@JoshCGrossman
52. THANKS FOR LISTENING!
Josh Grossman
Bounce Security
josh@bouncesecurity.com
https://JoshCGrossman.com
@JoshCGrossman
52
• Strategic and collaborative approach
• Software security is software quality
• Meet developers where they are
• Tools should support a wider process
Questions?
54. Agenda
54
1. What is IR?
2. Why appsec team?
3. End 2 End Process (Roles and Responsibilities)
4. PPT (Processes, People, Technologies)
5. Example
6. Summary
55. Incident Response Overview
55
Incident response is an organized approach to addressing
and managing the aftermath of a security breach or
cyberattack. The goal of an Incident Response plan or
procedure is to handle the situation in a way that limits
damage and reduces recovery time and costs.
58. Why Application Security Team?
58
1. Software Security - special knowledge
2. What if we are not affected?
3. Research for attack path (scan for vulnerabilities)
4. Safe money, time and effort
5. Response to Customers (Justification)
6. Remediation options and fix verification
59. Where AppSec team will help
59
Response
Provide technical advisory
justification for customers. Do
a research for attack
breadcrumbs inside logs,
publish CVE. Discuss
holistic solution for specific
issues.
Research
Understand vulnerability
details, create attack
simulation. Explain attack
vector to appropriate
stakeholders. Communicate
with external
researchers/customers to
obtain more details.Work
with R&D teams to verify
issue applicability..
Recovery
Provide technical
suggestions and guidelines
for remediation. Work with
R&D and DevOps/Operations
teams to provide workarounds
(temporary mitigations) if
need. Verify mitigation code
(code review, test security fix)
64. Conclusion
64
1. Critical zero days CVE’s - should be part of IR
2. AppSec team can safe you money and effort
3. Security champions - your best friends
4. Use security tools if possible
5. Response to Customers - AppSec team responsibility to
provide a justification
67. What is ASPM?
A new class of solutions and technology to help managing appsec, efficiently and at scale
It is based on the following principles
Complete visibility Secure the environment Contextual prioritization Collaboration & automation
69. What do we get from extreme visibility?
Respond to an event – vulnerable Jenkins plugin, Log4Shell
Find critically insecure configurations
Plan what we need?
71. Fix More Risk No more new
You must do it simultaneously
DevSecOps guardrails
Secure infrastructure
Developer awareness
Automated remediation
Find smarter ways to prioritize.
Root causes
Bulk operations
Exploitability / reachability
73. How ASPM helps #2 – DevSecOps Guardrails
o A guardrail catches vulnerabilities
before they reach runtime
o It doesn’t have to be blocking
o Reduces load from security teams
74. How ASPM helps #3 – Git configuration security
Review required
MFA enforced for all developers
Only verified actions
Workflow can’t approve
themselves
And dozens more…
75. Getting started
Consolidate an inventory and map the attack surface
ASPM tools are available to generate gap reports
Configuration scanners – you can start for free ( see Legitify)
Start small- introduce security scanners. Don’t forget data