Secure Your DevOps Pipeline Best Practices Meetup 08022024.pptx
•
0 likes•16 views
Our technology, work processes, and activities all depend on if we trust our software to be developed in a safe and secure manner. Join us virtually for our upcoming "Secure Your DevOps Pipeline: Best Practices" Meetup to learn how to integrate security in the development process, DevSecOps advance methods, manage the implement secure coding analysis and how to manage software security risks.
Recommended
Recommended
More Related Content
Similar to Secure Your DevOps Pipeline Best Practices Meetup 08022024.pptx
Similar to Secure Your DevOps Pipeline Best Practices Meetup 08022024.pptx (20)
More from lior mazor
More from lior mazor (20)
Recently uploaded
Recently uploaded (20)
Secure Your DevOps Pipeline Best Practices Meetup 08022024.pptx
- 2. DevSecOps: AppSec in the DevOps World Bar Hofesh CTO & Co-Founder, Bright bar@Brightsec.com
- 3. Father of two CTO & Co-Founder of Bright DevSecOps enthusiast Lover of Open-Source Hardcore Linux user (yeah, I use Arch) Cyber Security Researcher 15+ years Developer 6+ years IT 8+ years DevOps 3+ years About Me
- 4. The Era of Pentesting
- 5. 8-12 months release cycles Critical security issues wait a minimum of 4 months for a patch Endless manual PT cycles The upside? - Security is in sync with development speed Waterfall and Security - The Before Times
- 6. Introduction to DevOps “We need to release quicker”
- 7. Introduction to DevOps Devops combines software development and information-technology operations as a means for improving and shortening the software development life cycle (SDLC) DevOps operates with the following goals: 1.Improved development frequency 2.Faster time to market 3.Lower failure rate of new releases 4.Shortened lead time between fixes 5.Faster mean time to recovery
- 8. The benefits of DevOps Improved Collaboration DevOps breaks down silos between development, operations, and other teams involved in the software delivery process, leading to a more cohesive work environment. Increased Efficiency and Cost Savings Automation of repetitive tasks and processes significantly improves operational efficiency, reducing manual errors and optimizing resource utilization. Continuous Monitoring and Feedback DevOps emphasizes continuous monitoring of applications and infrastructure, providing real-time feedback on performance and potential issues. Customer Satisfaction The rapid delivery of features, improved software quality, and responsiveness to customer feedback contribute to higher customer satisfaction. Sounds amazing right? so what can be the
- 9. When DevOps happened security fell behind Not Humanly Possible = Vulnerabilities in Production! A new build every 2-3 minutes Even the most skilled pentesting teams worldwide can’t complete an end-to- end test in under a day 24 hours / 2 minutes = 720 builds
- 10. Can’t we just hire more people? There is an imbalance of Developers to Security professionals, with the estimated ratio of 500:1 The Problem? 01 Growing Demand: As organizations increasingly rely on digital platforms and applications, the demand for AppSec professionals has surged. 02 Limited awareness: Lack of visibility and understanding about the importance of AppSec in the broader cybersecurity landscape 03 Resource Constraints: Organizations may face budgetary constraints that limit their ability to invest in AppSec 99.8% Developers 0.2% AppSec Professionals https://portswigger.net/blog/the-state-of-devsecops-latest-stats-and-trend
- 11. Security Learn to Sprint - Embrace DevOps Sharing Security with DevOps
- 12. What is this “security” we decided to share? More than 80% of breaches are Web Application Oriented The modern world is application centric source: Verizon DBIR 2023 Research
- 13. DevOps + AppSec = Security in SDLC Automation Quicker cycles means quicker fixes Finding issues early on
- 15. Introduction to DevSecOps DevSecOps is an extension of the DevOps philosophy, integrating security practices seamlessly into the software development and delivery process. DevSecOps emphasizes the collaboration and communication between development, security, and operations teams, aiming to build security into the development lifecycle from the outset.
- 16. Key principles of DevSecOps Shift Left Security DeBy integrating security practices from the beginning, teams can identify and mitigate potential vulnerabilities before they escalate. Automated Security Testing Automation is a core principle of DevSecOps to ensure rapid and consistent identification of security issues Risk Assessment and Compliance DevOps emphasizes continuous monitoring of applications and infrastructure, providing real-time feedback on performance and potential issues. Empowering Developers DevSecOps empowers developers to take an active role in security. By providing tools, training, and resources, developers can make informed security decisions.
- 17. Classic DevSecOps paradigm Development Static Application Security Testing (SAST) Open-Source verification Security training (for devs) CICD During Build Environment security and updates Post Build Dynamic Application Security Testing (DAST) Vulnerability Assessment Penetration Testing (PT) TESTING / STAGING Comprehensive Lane (Maximum depth, bigger scope) Fast Lane (minimal & fast) DE V OP S
- 18. Pros and cons in today’s AST approach Approach SAST DAST IAST User s Developers Security QA When Code Testing/Staging QA Pro s Early Detection Full view Best of both worlds (?) Con s Blind to full picture Needs a live target Worst of both worlds!
- 19. DE V OP S What is the future of DevSecOps? AppSec is in the hands of developers Auto-Generate security oriented Unit Testing Full CI/CD automation Immediate feedback of detected issues -> Fast remediation Actionable results -> Give developers only what they need to solve the problem (no noise)
- 21. © 2023 Playtika Ltd. All Rights Reserved. Rotem Reiss SCALING SECURITY TRADITIONAL CI CHECKS RISK-ORIENTED DEVSECOPS BEYOND
- 22. 22 Director of product security at Playtika ROTEM REISS Shifted from software development and DevOps to AppSec. An Open-source contributor. A Bug hunter. Responsible for multiple CVEs. Helped securing well-known organizations and products such as: Co-organized the first Israeli bug bounty community meetup. @2RS3C Can’t refuse to a good beer (IPA, wheat). A parent of three humans and four cats. Fun facts
- 23. 23 SPICE UP YOUR CYBER While many companies recognize the importance of application security, establishing an AppSec program in mature startups and enterprises is a long and intensive process.
- 24. For every 100 developers, aim for at least one dedicated application security professional Forrester
- 25. 25 52% of organizations have fewer than five application security professionals on staff Forrester, The State of Application Security 2021
- 26. 26 “The cybersecurity workforce gap is expected to reach 1.8 million by 2022, with a shortage of 3.12 million skilled professionals globally (ISC)2
- 27. Fun is one of the most important – and underrated – ingredients in any successful venture. If you're not having fun, then it's probably time to call it quits and try something else Richard Branson
- 28. 28 WHERE DO WE START DAST Secure Coding Training IAST SAST WAF/API Security EASM SCA Penetration Tests Bug Bounty Program ESTABLISHING AN APPSEC PROGRAM
- 29. VENDORS BE LIKE
- 30. How many applications in the company? How many developers in the company? How does the CI/CD look like? What are our crown-jewels? Compliance requirements (GDPR, SOC 2)? Who do we report to? What are our weak spots? Informed Decision-Making WHERE DO WE START 30
- 31. 31 31 Forget all the buzz words. Shift-left is not always the answer. WOMBAT Your Way to a Scalable AppSec Program: Wear a hoodie. Outline your assets. Mitigate low-hanging fruits. Build a responsible-disclosure process. Assess and protect weak spots. Track your security tickets in one place. THE HAPPY PATH For us at least...
- 32. 32 SHOW ME HOW IT’S DONE
- 34. 34 YOUR ASSETS
- 35. Fetching domain names from various sources. How it works? Connect D-Collector to your cloud providers. D-Collector to fetch all DNS records from the connected cloud providers. D-Collector to create a unified structured file with all the DNS records. Published on GitHub. PlaytikaOSS/D-Collector OUTLINE YOUR ASSETS 35
- 36. We got domain names, how about URLs? Pulling publicly known URLs from GAU(*). Fuzzing URLs from common wordlists. 36 Fuzzing & Gathering URLS OUTLINE YOUR ASSETS
- 38. Wrapper for Nuclei, an open-source template-based vulnerability scanner. Running multiple periodical scans. Integrates to Jira via jTrack. Contributed to Nuclei as part of the project. 38 Code name: NHunt MITIGATE LOW HANGING FRUITS
- 39. Wrapper for the open source XSS vulnerabilities scanner Dalfox. Automated periodical scans. Integrates to Jira via jTrack. 39 Code name: CXSS MITIGATE LOW HANGING FRUITS
- 40. In-house tool for finding hijackable dangling domains. How it works? Takes all domains (from D-Collector). Takes all of the organization’s known registered cloud IPs. Compares the resolved IPs of external domains to known IPs. Recently published on GitHub. 40 PlaytikaOSS/DDFR – Dangling Domains Finder MITIGATE LOW HANGING FRUITS
- 41. WPscan wrapper – WordPress vulnerability scanner. 41 WordPress Scanner MITIGATE LOW HANGING FRUITS
- 42. Keep your source code under control. Identify code leakage as it happen. Integrates to our SIEM. Available on GitHub. 42 PlaytikaOSS/Leaktopus MITIGATE LOW HANGING FRUITS
- 45. 0-BUDGET Free VDP Security.txt / Humans.txt PAID ALTERNATIVES Bug Bounty Program • Internal • Private/Public 45
- 46. 46 ASSESS AND PROTECT WEAK SPOTS
- 47. After you’ve outlined your assets, and mitigated the low hanging fruits you can proceed with finding the common ground of the identified risks and focus your program on those. Examples: SaaS platform with various integrations – Resilience from SSRF vulnerabilities. Multi-tenant & multi-roles SaaS platform – Broken authorization vulnerabilities. A gaming company - Business logic vulnerabilities. 47 Finding the common ground ASSESS AND PROTECT WEAK SPOTS
- 48. 48 TRACK YOUR SECURITY TICKETS IN ONE PLACE
- 49. Anything to Jira integration. Manages (tracking) tickets state. Available on GitHub. 49 rotemreiss/jTrack SECURITY TICKETS TRACKING
- 50. THE FULL PICTURE Continuous Recon . . . Nhunt CXSS DDFR WPScan jTrack External Domail Names D-Collector EASM Product
- 52. Have a feedback loop of automated regression tests. Motivation: Developers have a clear acceptance criteria. Manual retest efforts are optimzed. Do you automate everything? No! Easy to automate + High chances for regression, e.g., unintentionally publicly exposed endpoints/data. Introducing regression tests REGRESSION TESTS 52
- 53. A single code repository of custom Nuclei templates. Pentesters & security champions to contribute PRs. Auto-update and tests execution once a day. 53 Technical details REGRESSION TESTS
- 55. How and when should we know about new features? How can we identify risky changes in real-time? How can we shift left and test features as early as possible, while keeping the business running at the same velocity as before? How can we cover a wider attack surface with the same means (budget and personnel)? Shifting Left AGILE PENETRATION TESTS 55
- 56. Software architects ++. Steering committee with the various business-units. QA teams to compose “abuser-stories” … Too much talk, not enough rock! Shifting left AGILE PENETRATION TESTS 56
- 57. GO DEEPER 57
- 58. Focus on risks, not (only) vulnerabilities. Identify them early. Risks often leads to vulnerabilities. Vulnerabilities with context. Continuously look for risky changes. Fuel our penetration testers with precise and impactful challenges. Motivation RISK BASED APPROACH 58
- 59. Brainstorming Retrospect known vulnerabilities to find the introducing material changes BACK TO REALITY Commonness Impact Implementation 59 EVERYTHING IS POSSIBLE
- 60. Material Change Priority Effort Type Internal API exposed publicly High Medium Infrastructure As Code New published infrastructure High High Infrastructure As Code Change in CSP policy Medium Low Application Package suspected as typosquatting introduced to code Medium Medium Supply Chain PII saved to logs Low Low Application 60 We have a plan RISK BASED APPROACH
- 61. Given a PR is opened When a new API route is introduced/modified When the route is processing user input When the user input property name is prone for “unintended behavior”, e.g.: url ⇒ SSRF redirect_url ⇒ Open redirect Then place a comment in the PR Then require a security review Example #1 RISK BASED APPROACH 61
- 62. Example #1 – Developer Experience RISK BASED APPROACH 62
- 63. 63 The “Magic” Behind Example #1 RISK BASED APPROACH
- 64. Given a PR is opened When CSP (Content-Security-Policy) is changed Then Create a challenge for the team Example #2 RISK BASED APPROACH 64
- 65. Given a PR is opened When a URL is present When the URL is a takeable sub-domain Then Block the PR with a relevant comment Example #3 RISK BASED APPROACH 65
- 66. Example #3 RISK BASED APPROACH 66
- 67. Detect material changes from more sources (other than SCM). Analyze documentation. More AI usage. Our vision RISK BASED APPROACH 67
- 68. Create your own risky changes rules. We are planning to release an OSS framework for easily creating more rules. Shift-left, but only when you’re ready. Use open-source tools to map & attack your external attack surface. Make sure you have a full vulnerability management lifecycle. Track all your tickets in one place. Verify fixes (retests). 68 WRAP-UP
- 69. 69 ASK ME ANYTHING @2RS3C https://www.linkedin.com/in/reissr/ Read more on our approach at https://www.playtika-blog.com/
- 71. Cyber security Balance Eddie Harari Infinitylabs R&D Cyber division
- 72. About me: - Eddie Harari AKA: TheGremlin - 30+ years of experience in cyber security worlds - Worked for Gov & Mil organizations - M + 4
- 73. What is cyber security balance ? Cybersecurity balance refers to the delicate equilibrium that organizations and individuals must strike between ensuring robust security measures and maintaining a level of usability and convenience. Achieving this balance is crucial because overly stringent security measures may impede productivity and user experience, while insufficient security can expose systems to various cyber threats.
- 74. Technology vs Policy & Methodology - Which of the two is more important ? - Which gets most of the focus ? - Why ?
- 75. The Risk Assessment process - Cyber security is dynamic field, Risk Assessment should be a periodic task. - Trying to get everything right on the first time will usually fail, we need to prioritize risks based on impact and likelihood.
- 76. User Awareness and training - Technical people are not immune to lack of awareness. - Build security-conscious culture within your technical teams as well.
- 77. Adaptive security - Cyber security is a dynamic topic and threat landscape always changes. - “In god we trust, all others we monitor”
- 78. Prepare for the day after the attack - Prepare procedures for IR and recovery - Conduct drills and simulations of attacks to ensure swift response
- 79. Deploying new security technology - What are the correct questions to ask when thinking about new security technology deployment ?
- 80. Thank You Q&A In god we trust, all others we monitor.
- 81. Thank You! Questions? To be continued… https://www.linkedin.com/company/application-security-virtual-meetups
Editor's Notes
- Rotem
- Rotem The meetup agenda is to talk about DevSecOps, but what is DSO? Is it only the left side of the SDLC? I believe that you can’t focus only on one side, you need to create a good balance between all sides.
- Rotem Is there a problem? Hell ya!
- Do you think its enough?
- Rotem
- Rotem If you didn’t have enough quotes till now, here’s another one We must have fun when establishing and running an appsec program.
- Rotem Starting an appsec program is confusing. The application security iceberg is enormous and we can look at it from various angles (shift-left/shift-right). So would you start from SAST, DAST….?
- Rotem
- ROTEM No one knows the organization better than you, therefore you should decide how and where to start. A few questions to help you find your way. At the end this should allow you to better understand the risks in your products and the efforts in protecting it. Protecting a single product is different than protecting 10 or 100 products Small R&D teams is easier to work with and the feedback cycle is way shorter. The ratio between appsec <> developers is also a huge factor ofc. Is your CICD solid or a jungle? Do you even have a clear CICD? Crown-jewels are heavily related to the compliance requirements (e.g., PCI, GDPR) Regulations might shift your program to a specific path which is not necessarily the ideal one (risk-wise). Who do we report to? CTO? R&D? IT? This might be where we can have the biggest effect with a minimal effort. In our case it helped us with working very close the our software architects and treat them as security champions by definition. What are our weak spot? Try to identify the main risks in your products and act according to that. If you don’t have all the answers, get them and try again.
- Rotem
- ROTEM I’ll hand over the stage to that will show you how it’s done.
- We started to think, can we take our bug hunting experience and apply it here? As bug bounters we keep learning about new technologies and vulnerabilities, and applying this to our methodology.
- Mapping – externally first, only then internally.
- Supported providers: Prisma Cloud AWS GCP DigitalOcean Manual list - Giving it relevant API keys or tokens. - (A and CNAME records) - unified json format Also can provide internal domains to classify as private {"name": "domain name", "record_type": "DNS type (CNAME,A)", "record_value": "value (ip,ec2 domain name)", "is_private": "false/true", "source": "provider/dns management tool"}
- For scanning and attacking we need urls. Most of the vulnerabilities are just sitting there on the root directory. There could be numerous web applications for any domain name. There is the passive way: GAU – getallurls, open source tool for gathering publicly known urls from various sources like AlienVault, Wayback Machine and more. And the active way - fuzzing.
- Low hanging fruits are security vulnerabilities that are easy to exploit and are simple for attackers to identify. These are good vulnerabilities to start with because: Quick wins: Having some quick wins can help build momentum for the team and can help in showing quick value. If we can easily find them so can attackers. And not sophisticated ones, script kiddies. Exploitation and identification of them of them are easy to automate.
- Talk about why we need the wrapper: back in the day there was no integration with jira. Functionalities that nuclei doesn’t support out of the box For critical vulns we are running more frequent scans, every few minutes until 1 week. To work with D-collector format, modularity by threads, severity, etc. Talk about how we contributed.
- Automatic scanning of Playtika’s public brand sites.
- ROTEM I won’t elaborate on Leaktopus too much, but if someone wants to know more, get into the repo or watch my talk on code leakage detection from Bsides TLV. In short, Leaktopus allows us to detect code leakage with a very short MTTD.
- ROTEM
- ROTEM Responsible disclosure process doesn’t necessarily mean budget allocation and a paid bug bounty program. It means that at least security researchers and bug hunters should know who to contact in case they found something. Let’s go over the two alternatives – with or without budget allocation.
- 0 budget Start with embracing the security.txt standard Vulnerability disclosure program Suprisingly the vulnerabilites we got from the internal plan were critical and insightful – I can add our pains and solutions regarding the private program. For exmaple, if you have several products, systems, which are a businness unit of their own (like our), you need to prioritize so you don’t end up with a negative ROI. In our case we did a tier based policy, detemined by the priority of the company for the specific businness unit.
- Rotem Hacker/ Bug-hunter methodology POV (Tinfoil hats on!)
- ROTEM Once you are focused, you can better decide on the tools to use and where to put your effort. This applies both to tactic and strategic decisions.
- An in-house tool written in Python Easily integrate to Jira Tickets state – will open new tickets if the ticket with the same jtrack id is closed.
- So, when combining all of our tools you get something we call Continous Recon. The idea to have plug & play tools that will work with the input from our recon tools and output to our R&D/OPS easily All of this while keeping in mind several “rules”: Focusing on impactful and relevant vulnerabilities with near zero false positives Have an automated process with the least needed AppSec human touch Keep learning and improving, if its from the community, from reports to our bug bounty program, etc. We didn’t abandona classic vendor based EASM, on the contrary, we enrich it with our tools and vice versa.
- The process isn’t perfect without retesting our vulnerabilities once closed. The older sibling “QA” already have a solution for it – Regression tests. 28 Minutes
- - Acceptance criteria definition for developers instead of plain-text recommendations.
- The repository is organized by folders for each vulnerability, in each folder a list of relevant targets and the template.
- Rotem
- Rotem Traditional PT is not cost-effective, and has many problems. Without specifying all the cons, we can only list one - imagine that a critical vuln. was released a day after your annual or quarterly PT. So we decided the be more agile like our R&D teams, we did it by first answering a few questions and defining our main constraints.
- Rotem All software architects as security architects Threat modeling, as part of their high-level designs Get a second opinion from us on any high-risk features. This made it possible for us to be kept in the loop, on most cases. Once every six weeks, we meet with every business unit’s stakeholders to discuss the security maturity of said business units. vulnerabilities status and new features Stay up to date on new features, infrastructure changes, managerial changes, and roadmaps Train QA teams to change their mindset and think also on the sad path.
- Rotem
- Rotem
- Brainstorming also with other teams, e.g., corporate security – Azure apps. Priority = risk level + commonness in the company. Effort = Can we implement with existing tools?
- We are looking at the use cases, at first in a “fantasy world” where anything is possible. Then we prioritized them according to our needs. Then we thought, can we use existing tools to implement this use case? If not, can we develop the necessary framework ourselves?
- Suspicious PR – Find suspicious parameters in a PR. Review by Pentester, Architect, Champions.
- Content security policy is a sensitive thing and each minor change could make it useless.
- "Given-When-Then" - provides a clear and structured approach to testing in small chunks. Takeable subdomain URLs scanner - looking for the use of takeable domains in code.
- "Given-When-Then" - provides a clear and structured approach to testing in small chunks. Takeable subdomain URLs scanner - looking for the use of takeable domains in code.
- Rotem When things are in code it’s easy, what about other cases like integrations with other systems (Azure, WAF and etc.).
- Rotem +