Operationalizing Red Teaming for Fun and Profit
•
1 like•481 views
Ian Allison - Security Testing and Red Team, Devsecops Red Teaming is one of the cornerstones of the DevSecOps philosophy. By actively testing a product or environment it is possible to get ahead of attackers. However, as we found out not every organization is ready for the full onslaught of a dedicated and skilled Red Team. This talk will cover the journey we have taken to grow our Red Team from a grassroots concept into a highly sought out and elite function within our organization. We will cover the highs and lows we have experienced during our journey. Ultimately, we will show how we have matured the Red Team function to be able to illustrate risk in a real and concrete manner while still having fun and popping the occasional shell.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to Operationalizing Red Teaming for Fun and Profit
Similar to Operationalizing Red Teaming for Fun and Profit (20)
More from Sonatype
More from Sonatype (20)
Recently uploaded
Recently uploaded (20)
Operationalizing Red Teaming for Fun and Profit
- 3. November 15, 2016 @iallison • Commodore 64 -1984 • 300 Baud Modem • LOAD "*", 1, 1 • BBS • Lots of txt files
- 4. November 15, 2016 Background • Large Scale Linux Admin • IT Security Audit • Cyber Wargames Designer and Operator • Offensive Security Instructor • Penetration Tester • Embedded Device Security Tester • Security Researcher
- 5. November 15, 2016 This Path Leads To • Developers are stupid • Developers don’t care about security • Developers just care about deadlines • DevOps are even worse! • Until ….
- 6. November 15, 2016 Chasing the Red Rabbit A.K.A DevSecOps • In my first week write a microservice API and get it securely into production in the cloud • Instant developer empathy • Iterate code, security and secure deployment in the cloud • All security applications are hosted in the cloud
- 7. November 15, 2016 Second Step into DevSecOps • How do you make sure all your baseline images are safe? • How do you do it for thousands of AWS accounts? • You have to write your own automation • Learn the inner workings of your cloud provider
- 8. November 15, 2016 Scanners Suck • Spray and Pray • Only as good as their signatures • Remediation guidelines are not actionable • False positives abound • Who else loves reading 200 page PDFs?
- 9. November 15, 2016 Scanner Vendors Suck • Usually have proprietary on host databases (kills cloudiness) • Hard to correlate same vulnerability across multiple vendors • Don’t share as much as they should By Clark Stanley [Public domain], via Wikimedia Commons
- 10. November 15, 2016 Traditional InfoSec • Compliance • Regulations • Appliances • Perimeter A.K.A ”Bow to my Firewall” –Bruce Potter
- 11. November 15, 2016 InfoSec is Selfish • Good at saying NO • Remediation is up to the developers • Feedback is a Scanner report • Only solves for security and compliance not developers • Don’t like to share
- 12. November 15, 2016 Trends in the Media • SaaS for DevOps Security • Collaborative Security • Tools, CICD, appliances and CASBs oh my • Configuration Management is the answer to everything • Compliance will help protect you
- 14. November 15, 2016 The Golden Ratio • Research varies as to the ratio of Security to Developers • 1 to 1000 to 8.5 to 100 • 1 to 5000 networked devices! • What if Security and DevOps were one in the same? http://www.infosecisland.com/blogview/8327-How-Many-Information-Security-Staff-Do-We-Need.html
- 15. November 15, 2016 DevOps == Opportunity • Can be an amazing thing when done right • Fast, lean and efficient and secure • Integrate security checks with CICD and catch low hanging fruit • Security needs to learn how to adapt and evolve or it could become irrelevant • When DevOps is done wrong ...
- 17. November 15, 2016 How Do We Make it Better? • Allow Dev teams to assume the risk of their decisions • No more Security exceptions or sign offs • Security is everyone’s responsibility • Test the crap out of your own stuff like an attacker would
- 18. November 15, 2016 Reality • Scanners find the absolute bare minimum • Bad default configs are a HUGE problem even with SaaS vendors • Manual testing can uncover defects that have been hiding for years • The attackers are more skilled and motivated
- 19. November 15, 2016 Getting Dirty • Started small, lean and focused on the cloud • Worked like an Agile DevOps Team • Found, reported and fixed thousands of vulnerabilities not found by scanners • This was all done manually with the use of some tools
- 20. November 15, 2016 What is a Red Team? • Use same tactics as attackers • Only scope is “Don’t take down production” • Need to adapt and evolve like an attacker • Prove risk actually exists • Should be writing their own exploits • Should have ongoing campaigns that mimic attackers
- 21. November 15, 2016 Red Team Mindset • Use applications in ways they are not intended. • Not just technology focused • Silent Intruders • Physical Security • Social Engineering • Phishing/Spearphishing • Waterhole attacks
- 23. November 15, 2016 Red Team != Penetration Testing • Pentesting is tightly scoped • Non-realistic attack scenarios • 5% fun 95% meetings and reporting • Quickly becoming a type of compliance
- 24. November 15, 2016 Some of the Tools Used • nmap • curl • BurpSuite • Metasploit Framework • Gauntlt • Github • Shodan.io • Jira – Case Management • Multiple cloud providers • Jenkins – For automation/scheduling • Nexus – For finding bad libs • Homemade tools
- 25. November 15, 2016 Impacting Release Schedules • Defects can cause churn • Can cause escalations to upper management • Forces tradeoffs between releases and security • Can create contention between security and Dev teams • Pivoting can be hard for non agile teams
- 26. November 15, 2016 Lessons Learned • You can actually move too fast • The more automation and APIs you provide developers the better they respond. • Having a central source of recon data is critical to finding targets • Hard to switch context from attacker to helper
- 27. November 15, 2016 Security Defects • Defect vs Vulnerability • Security people suck at speaking developer • Understanding your audience (Developers) is critical • Clearly explaining the issue with a PoC is a teaching opportunity
- 28. November 15, 2016 Reporting • Defects go directly into a Dev team’s backlog • Graded ( A – F ) • Dev Team decides priority of defect • Reported all the way up • First thing in defect ticket is remediation guidance • Includes checks for validating remediation for Dev Teams
- 30. November 15, 2016 How We’re Making it Better • Feedback is a gift! • Show our upcoming targets the week before • Automated attacking the low hanging fruit • More transparency • Metrics, Metrics and more Metrics • Helping our vendors with better remediation guidelines
- 31. November 15, 2016 But Does it Blend? • We see a lot of data come across the wire • How do you find the needle in the haystack? • Attackers and attacks are constantly evolving • It takes more than just a Red Team, it takes a DevSecOps team Source: https://www.flickr.com/photos/ciuu96/
- 33. November 15, 2016 Current State • Focusing on automating security testing into CICD • Using Jenkins as our C&C for Red Team and Security Testing Activities • Scanning and attacking Kubernetes and Docker containers • Getting shells before the attackers through application exploit development
- 34. November 15, 2016 Get Involved & Join the Community • devsecops.org • @iallison on Twitter • DevSecOps Group on LinkedIn • DevSecOps on Github Huge shout out to Shannon Lietz A.K.A @devsecops