Securing the Third-Party Software Supply Chain
•Download as PPTX, PDF•
0 likes•178 views
Today, a significant percentage of all software is assembled from open-source software and COTS. Akin to a baker who didn’t grow their ingredients, how well do development teams know their ingredients and the inherent risk they carry? This webinar provides an understanding of how to “shift left” in a DevOps SDLC by conducting early stage scrutiny to better manage software risk. Topics include: •Choosing components wisely to reduce attack surface •Ongoing threat modeling •Cloud configuration and deployment review •Procurement strategies and contracting tools •Mitigating weaknesses in supply chain elements
Recommended
Recommended
More Related Content
More from Security Innovation
More from Security Innovation (20)
Recently uploaded
Recently uploaded (20)
Securing the Third-Party Software Supply Chain
- 1. 1 , CEO of Security Innovation
- 2. 2 About Security Innovation • Securing software in all the challenging places…. • ….while helping clients get smarter Assessment: show me the gaps Standards: set goals and make it easy Education: help me make good decisions Over 3 Million Users Authored 18 Books Named 6x Gartner MQ
- 3. 3 About Me • CEO by day; engineer by trade (and heart) • Mechanical Engineer, Software Engineer • Ponemon Institute Fellow • Privacy by Design Ambassador, Canada • In younger days, built non-lethal weapons systems for Federal Government
- 4. 4 Agenda Managing Procurement & Supply Chain Risk Threats & Attack Vectors Cloud Configuration & Deployment Review
- 5. 5 DevOps and 3rd-Party Software Still need documented steps and standards to follow along properly SLA SLA Configure (cloud services/infrastructure) Your data OSS/GitHub Buy
- 6. 6 COTS: Co-Owning the Software • 73% of breaches from 3rd-party ecosystem* • Quest Diagnostics: hacker accessed data via billing collections software • Facebook: passwords & email addresses exposed via 3rd party app • Focus Brands: Point of Sale (PoS) software hacked • Target: $292M in cost associated with 2013 data breach** • HVAC software vendor’s fault (Fazio) • Ruling is they failed to identify and mitigate data risks • Can’t just rely on patching. Anticipate deployed scenario weaknesses • Inaccessibility to code forces you to take a more risk-based approach * 2019 Verizon Data Breach Report ** 2016 Target Annual Financial Report
- 7. 7 Polling Question What percentage of your solution(s) would you estimate is COTS/3rd - party versus custom code? 1. Don’t know/can’t estimate 2. Less than 30% 3. 30-70% 4. More than 70%
- 8. 8 Acquisition Strategies • Recognize threat and prevalence of 3rd-party software • To reduce counterfeits, theft, tampering, malware, etc. • Obscure end use of systems • Use blind or filtered buy process • Require tamper-evident “packaging” • Use trusted (and verified) distribution channel
- 9. 9 Supplier Review Checklist Implement security and privacy controls Provide transparency into their development processes Accept contractual responsibility for tainted/insecure components Provide additional vetting of their subordinate suppliers Restrict purchases from certain subordinate suppliers Require the developers of systems/components or providers of services to: • perform criticality analysis of their offerings • provide, implement, and test incident response plans
- 10. 10 Safeguarding the Supply Chain • Avoid non-standard configurations • Use trusted and diverse suppliers • Risk must be tackled across procurement, design, development, and sustainment • Prioritize risk by both likelihood of occurrence and severity of impact • Establish criteria for mitigating threats and reducing impact of incident
- 11. 11 Assessing 3rd Party Software • Not very different from assessing your own; same attack methods apply • You don’t have access to the source code to fix vulnerabilities in COTS software • Implement controls to reduce those risks, e.g., WAF • This makes risk mitigation for COTS software tedious … but achievable • Cloud • Wonderful scale and “turn-key” operations • Loads of (new) deployment configuration issues to consider • Info gathered from assessments • Improve the supply chain procurement processes • Inform the supply chain risk management process • Serve as foundation for additional testing or SLA conversations with 3rd-parties
- 12. 12 Threat & Attack Vectors 12
- 13. 13 Threat & Risk Identification • Initial Threat Modeling • Robust • Business and Risk focused • Can be done before any code bought/built • Updates to Threat Model • Significant system change • Realization of new threats • New security-related development • e.g., authentication Dataflow Model courtesy of OWASP
- 14. 14 Understanding & Quantifying Threat Risk • Security audit and reviews • Simple questionnaires vs. technical analyses • Threat Modeling - important to know all the critical assets COTS software will interact with • Analyze entry and exit points • Create risk profiles for each key asset • Analyst and rate risks • Dynamic Analysis / Penetration Testing • Even if you can’t fix the problem identified, you can mitigate it • Responsibly disclosing vulnerabilities can improve partnership with ”in this together” communication • Red teams & Attack Simulations of IT infrastructure • Objective-based options: can you compromise/access asset X? • Attackers often use a vulnerability in low risk application to escalate privilege • To an attacker, all applications are potential entry points
- 15. 15 Reducing Your Attack Surface • Software exposes key business & customer assets via entry points • Primarily driven by the principle of least privilege • Remove all software, components, features that aren’t required • Disable features of software and services that aren’t essential • Choose components that meet requirements by default • Minimize configuration and/or ”glue code” development • It’s your data; protect it • Custom apps, COTS, OSS … doesn’t matter • Encryption requirements simplest to set
- 16. 16 Additional Measures to Reduce Risk • Assign owners for your riskiest 3rd party applications for • Regular testing & analysis • Vendor communication • Segregate data • Complements encryption • Minimizes compliance scope • Have an accurate inventory of all your COTS applications • Including the libraries & components that are used to make third-party software • Consider endpoint and content filtering solutions as part of a defense-in- depth strategy, • e.g., antivirus, web filtering, DLP, IPS, AWS/Azure configuration settings
- 17. 17 Cloud Configuration & Deployment Review 17
- 18. 18 Double Check Firewalls & Security Groups • Same as internet connected traditional infrastructure • Minimize open ports (80, 443, 3306) • Consider disabling direct access • Require an additional hop for critical infrastructure • Do both! • Security Groups and Azure Firewall rules are great Infra Level protection • Manage your own server level firewalls for a belt and suspenders approach
- 19. 19 Authentication • AWS/Azure/GCP tie Authentication and Authorization together • Keep them separate in your mind - threats are different • Authentication is about identity, Authorization about access • Authentication to your Cloud Provider is critical • Imagine what someone could do with direct access to your infrastructure from anywhere in the world • MFA/2FA is well supported on all platforms • Don’t discount SIM cloning attacks for critical infrastructure
- 20. 20 Authorization • Who has access to what is complicated in the cloud • AWS Cognito and Azure AD define access to servers through • Firewalls, roles, service configurations or network configurations • Some “features” like AssumeRole for temporary access can be abused • Storage buckets can be world readable • This has led to an enormous number of data breaches • Point is that a lot of thought needs to go into cloud configuration
- 21. 21 Upguard RNC Breach • Accidentally exposed 200 million voters due to an open S3 bucket • Lesson learned: • Need to understand underpinnings of the cloud infrastructure • Had Upguard configured their AWS S3 bucket to not allow download or access privileges, could have been avoided • Why attack simulations and red teaming are necessary • Would have likely found the dra-dw amazon subdomain, realized it was an attack vector, and secured it Misconfigurations, both obvious and obscure, happen frequently with cloud operations; thus, regular scrutiny is necessary Real World Cloud Misconfiguration
- 22. 22 Encryption – What Could Possibly go Wrong? • Can be offloaded to cloud services • Configuration and use can be challenging • Key Rotation, Automatic Key Removal, MFA, can and should be automated • Ties access to a user/role, not a key • Secrets Manager & KMS – Stores keys safely • Encryption Services – Stores data securely
- 23. 23 Scaling a Two-sided Sword • One of the great benefits of the cloud – meet demand as necessary • But you pay for it • Attackers can see both sides • DDoS Attack without scaling leads to a true DoS • DDoS Attack with scaling may rack up costs • Cloud services can help a bit, but need to be part of a broader deployment strategy
- 24. 24 Final Thoughts • Conduct a supplier review prior to entering contractual agreement • Conduct an assessment of the COTS prior to selection, acceptance, or update • Treat 3rd party software/components as you would your own • Perhaps riskier since you have less visibility and often no code access • It’s important for organizations to have sufficient knowledge of where and how COTS software will be deployed • As well as a review of known vulnerabilities • Threat Model and Attack Surface Reduction are your best friend
- 25. 25 How Can We Help? Secure SDLC Risk Review • Fill compliance gaps with tools, activities and skills • Roadmap with optimal sequencing Computer Based Training • Covers all major technologies, roles, frameworks • Maps to PCI DSS, GDRP, OWASP, ISO, NIST, NERC, CSSLP, CWE, HIPAA Cyber Range • Authentic, turn-key, fun • Reports map to specific courses • Identify champions
- 26. 26 Questions?
Editor's Notes
- Use the acquisition process during the early stages of the system development lifecycle to manage supply chain risks. [2] Some ways that the acquisition process can be used to protect the supply chain include: Obscuring the end use of systems and components; Using blind or filtered buys; Requiring tamper-evident packaging, and; Using trusted distribution. [3] These techniques can help defend against counterfeits, tampering, theft, unauthorized production, malware, and poor manufacturing and development practices. [6] Consider providing training to staff that covers the organization's strategies for managing supply chain risk. 1] When choosing suppliers, it is strongly recommended to review the ability of the supplier to assess their subordinate second-tier and third-tier suppliers. [2] The reviews should look for indications of stolen information, poor development practices, poor quality control, unauthorized information disclosure, tampering and counterfeiting. [3] The reviews can be based on publicly available information and process documentation. If other sources of information about the suppliers are available, those sources of information can be used as well.
- Supply Chain Risk Management includes implementing safeguards for reducing the probability of successful attacks on the supply chain. To safeguard the supply-chain: Avoid purchasing non-standard configurations; Use multiple different suppliers; Use trusted vendors; Design the system to include diverse components, and; Minimize the time between purchase decisions and taking delivery
- Threat & Risk Identification Having an accurate and complete inventory of all your COTS applications is a key component. Make sure you are aware of all the libraries and components that are being used to make up the software by the third-party vendors. You can better understand risks by conducting a variety of analysis and testing techniques including: • Security audit and reviews. These can be as simple as questionnaires as opposed to technical analysis. • Threat Modeling. It’s important to know all the critical assets COTS software will interact with. These assets can be identified through threat model exercises: o Analyze entry and exit points. o Create risk profiles for each key asset. o Once you have you analyzed and evaluated risks, rank them and address the highest priority risks first. • Conduct Penetration Testing. You may find vulnerabilities the ISV doesn’t know about. Responsibly disclosing vulnerabilities to the ISV can help cement a stronger partnership and facilitates open communication with the vendor. Learn about our software penetration testing approach. • Conduct red teams and attack simulations on your IT infrastructure with very specific goals in mind (i.e. stealing your most sensitive IP) to understand which 3rd party (and even internally developed) applications are putting your enterprise most at risk. Attackers often use a vulnerability in a low risk application to gain access to more valuable targets via escalation of privilege and application traversal. This isn’t limited to COTS software or internally developed applications… to an attacker, all applications are potential entry points.
- You can better understand risks by conducting a variety of analysis and testing techniques including: • Security audit and reviews. These can be as simple as questionnaires as opposed to technical analysis. • Threat Modeling. It’s important to know all the critical assets COTS software will interact with. These assets can be identified through threat model exercises: o Analyze entry and exit points. o Create risk profiles for each key asset. o Once you have you analyzed and evaluated risks, rank them and address the highest priority risks first. • Conduct Penetration Testing. You may find vulnerabilities the ISV doesn’t know about. Responsibly disclosing vulnerabilities to the ISV can help cement a stronger partnership and facilitates open communication with the vendor. Learn about our software penetration testing approach. • Conduct red teams and attack simulations on your IT infrastructure with very specific goals in mind (i.e. stealing your most sensitive IP) to understand which 3rd party (and even internally developed) applications are putting your enterprise most at risk. Attackers often use a vulnerability in a low risk application to gain access to more valuable targets via escalation of privilege and application traversal. This isn’t limited to COTS software or internally developed applications… to an attacker, all applications are potential entry points.
- Mitigating And Reducing Risk A primary tenant of security is limiting your attack surface. This can be accomplished by applying the principle of least privilege in several ways. First, remove all software from clients and servers that aren’t required. Consider Adobe Flash – it is found on almost every computer, and not usually necessary for day-to-day operations. Yet, it is riddled with security vulnerabilities and significantly expands your vulnerability footprint. Additionally, uninstall and disable features of software and services that aren’t essential. For example, most Java vulnerability exploits are carried out via web browser plug-ins. Most browsers allow the ability to disable plug-ins in the security and privacy settings. Make this part of your Information Security policies and review. Additional measures to reduce risk include: • Assign owners for your riskiest 3rd party applications for regular testing, analysis, and vendor communication • Segregate data and encrypt everything you can, both at rest and in transit. This has the addition benefit of helping you comply with industry regulations, such as PCI-DSS, HITECH, and others that require encryption of sensitive data. • Implement an application security training program for your development and IT operations teams. “An investment in knowledge pays the best dividends” – Ben Franklin • In addition to the application-specific controls mentioned above, consider endpoint and content filtering solutions as part of a defense-in-depth strategy, e.g., antivirus, web filtering, DLP, IPS, etc.
- allows any authenticated AWS user to assume this role and retrieve temporary credentials.
- The recent compromise of almost 200 million registered U.S. voters AKA, the Upguard RNC Breach, was accidentally exposed online due to an improperly configured database setting that resided in the cloud. The first lesson learned is that you still need to understand the underpinnings of the cloud infrastructure to take full advantage of its benefits. Had Upguard configured their AWS S3 bucket to not allow download or access privileges, this breach could have been avoided. This may sound oversimplified and in actuality, it sadly is - but the point remains that misconfigurations, both obvious and obscure, happen frequently with cloud operations; thus, regular expert scrutiny is necessary. This is also a perfect example of why regular attack simulations and red teaming are necessary – had Upguard conducted these, they would have most likely found the dra-dw amazon subdomain, realized it was an attack vector, and secured it in a proper manner.