Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The As, Bs, and Four Cs of Testing Cloud-Native Applications

212 views

Published on

Security assessments are a critical part of any security program. Being able to identify – and communicate about – vulnerabilities systems is required to get vulnerabilities prioritized for remediation. For web and mobile applications, assessment methodologies are reasonably straightforward and established. However, for cloud-native applications, the combination of new technologies and architectural elements has introduced questions about how to scope, plan, and execute security assessments. This presentation looks at how the assessment landscape has changed with the introduction of cloud-native applications and explores how threat modeling is central to testing their security. In addition, the “Four C’s” conceptual model for looking at cloud-native application security is introduced, including a discussion of how both automated and manual testing methodologies can be used to accomplish assessment goals. Finally, vulnerability contextualization and reporting are discussed, so that teams running cloud-native application assessments can properly characterize the results of their efforts to aid in the prioritization and remediation of identified issues.

Published in: Technology
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ http://1url.pw/dJl9E ◀ ◀ ◀ ◀
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

The As, Bs, and Four Cs of Testing Cloud-Native Applications

  1. 1. © 2019 Denim Group – All Rights Reserved Building a world where technology is trusted. The As, Bs, and Four Cs of Testing Cloud-Native Applications 1 September 12, 2019 Dan Cornell | CTO
  2. 2. © 2019 Denim Group – All Rights Reserved Dan Cornell • Founder and CTO of Denim Group • Software developer by background • OWASP San Antonio co-leader • 20 years experience in software architecture, development, and security
  3. 3. © 2019 Denim Group – All Rights Reserved 3 Advisory Services Assessmen t Services Remediation Services Vulnerability Resolution Platform Building a world where technology is trusted How we can help: Denim Group is solely focused on helping build resilient software that will withstand attacks. • Since 2001, helping secure software • Development background • Tools + services model
  4. 4. © 2019 Denim Group – All Rights Reserved Agenda • The Good Old Days • The More Interesting New Days • Architectural Bill of Materials • Four Cs • Reporting • Tailoring • Questions 4
  5. 5. © 2019 Denim Group – All Rights Reserved The Good Old Days Blast it with SAST or DAST Do some manual testing, and …
  6. 6. © 2019 Denim Group – All Rights Reserved
  7. 7. © 2019 Denim Group – All Rights Reserved The More Interesting New Days 7
  8. 8. © 2019 Denim Group – All Rights Reserved The Even More Interesting New Days 8
  9. 9. © 2019 Denim Group – All Rights Reserved A Dedicated Server at Rackspace?! 9
  10. 10. © 2019 Denim Group – All Rights Reserved What Changed? 10
  11. 11. © 2019 Denim Group – All Rights Reserved An Aside: Why Did Things Change? • Digital Transformation • The “risk” we talk about is crap • Falling behind creates existential risk for firms • Must Go Faster? • Change culture to DevOps • Culture has changed to DevOps? • Adopt new technologies to support mission 11 https://www.denimgroup.com/resources/whitepaper/security-the-other-side-of-digital-transformation/
  12. 12. © 2019 Denim Group – All Rights Reserved What Changed? • Architecture • Monolithic -> Microservices • Technology • Cloud servers • Cloud services • Containers • Serverless • CI/CD Pipelines 12
  13. 13. © 2019 Denim Group – All Rights Reserved Microservices If you couldn’t make one big thing work properly, what makes you think you can make thirty smaller things that need to talk to one another work properly? 13
  14. 14. © 2019 Denim Group – All Rights Reserved How You Think Microservices Will Work 14
  15. 15. © 2019 Denim Group – All Rights Reserved How Microservices Actually Work 15
  16. 16. © 2019 Denim Group – All Rights Reserved As, Bs, and Four Cs • Architectural Bill of Materials • Four Cs • Code • Components • Compute • Cloud Configuration 16
  17. 17. © 2019 Denim Group – All Rights Reserved Software Bill of Materials (SBOM) • What is actually in the software I am shipping? • Open source, etc 17 OWASP Dependency Track https://www.owasp.org/index.php/OWASP_Dependency_Track_Project
  18. 18. © 2019 Denim Group – All Rights Reserved Architectural Bill of Materials 18
  19. 19. © 2019 Denim Group – All Rights Reserved Architectural Bill of Materials 19 • What are the pieces of the system we are looking at? • Being able to answer: • What are the various parts of the system? • What do they consist of? • What do they do? • Where are they hosted?
  20. 20. © 2019 Denim Group – All Rights Reserved Architectural Bill of Materials 20 • So a threat model? • Yeah pretty much. A threat model.
  21. 21. © 2019 Denim Group – All Rights Reserved High Level Threat Modeling Concepts Decide on scope 1 Build your dataflow diagrams 2 Enumerate threats 3 Decide on mitigations 4
  22. 22. © 2019 Denim Group – All Rights Reserved Creating Data Flow Diagrams (DFDs) • Decompose the system into a series of processes and data flows • Explicitly identify trust boundaries
  23. 23. © 2019 Denim Group – All Rights Reserved Example Data Flow Diagram
  24. 24. © 2019 Denim Group – All Rights Reserved Identifying Threats from the Data Flow STRIDE is expansion of the common CIA threat types • Confidentiality • Integrity • Availability STRIDE • Spoofing Identity • Tampering with Data • Repudiation • Information Disclosure • Denial of Service • Elevation of Privilege
  25. 25. © 2019 Denim Group – All Rights Reserved Mapping Threats to Asset Types Threat Type External Interactor Process Data Flow Data Store S – Spoofing Yes Yes T – Tampering Yes Yes Yes R – Repudiation Yes Yes Yes I – Information Disclosure Yes Yes Yes D – Denial of Service Yes Yes Yes E – Elevation of Privilege Yes
  26. 26. © 2019 Denim Group – All Rights Reserved So What Does That Leave Us? Take all the assets Associate threat types with each asset Voila! List of things we need to worry about
  27. 27. © 2019 Denim Group – All Rights Reserved ABOM • We at least need the results of Steps 1 and 2 to get our asset list and the relationships • May as well finish things off because we’ll need the rest later on to provide context for reporting 27
  28. 28. © 2019 Denim Group – All Rights Reserved Given our ABOM • We now need to look at the security of each of the pieces in the overall system • Test them for security issues at various layers • Aggregate the results 28
  29. 29. © 2019 Denim Group – All Rights Reserved Four Cs 29 Code Components Compute Cloud Configuration
  30. 30. © 2019 Denim Group – All Rights Reserved Code 30
  31. 31. © 2019 Denim Group – All Rights Reserved Code • This is the code you write • Business logic • Glue stuff together • Traditional focus of OWASP/application security • Automated testing with SAST, DAST, IAST • Manual penetration testing and code review 31
  32. 32. © 2019 Denim Group – All Rights Reserved Code – API Testing • Great news – the DAST tools you depended on for web application testing might not work terribly well for APIs • Some API-focused DAST tools • OWASP ZAP has some capabilities in this area • Always option to do manual testing 32
  33. 33. © 2019 Denim Group – All Rights Reserved Components 33
  34. 34. © 2019 Denim Group – All Rights Reserved Components • These are the open source components you include so that you don’t have to write everything • Libraries • Frameworks • Gained prominence with its introduction in the OWASP Top 10 2013 • Gained notoriety with the Equifax breach • Thanks, Struts… • Test with Software Composition Analysis (SCA) • Often need to manually validate impact • Traditional SBOM scope 34 https://www.owasp.org/index.php/OWASP_Dependency_Check
  35. 35. © 2019 Denim Group – All Rights Reserved Compute 35
  36. 36. © 2019 Denim Group – All Rights Reserved Compute • Something has to run all this code… • Virtual machines, cloud servers, containers • Serverless takes this to the extreme • Don’t forget dedicated servers • Test with: • Traditional vulnerability scanning • Container scanning 36
  37. 37. © 2019 Denim Group – All Rights Reserved Cloud Configuration 37
  38. 38. © 2019 Denim Group – All Rights Reserved Cloud Configuration • The squishiest of all the Cs • Maybe that’s why it gets two Cs… • Largely configuration checks • Open S3 buckets • Bad IAM set ups • Will evolve over time • If this presentation were being given a couple of years ago, cloud servers might fall in this category • Move stable stuff – cloud servers – into their own Category 38
  39. 39. © 2019 Denim Group – All Rights Reserved So What Does This All Look Like? 39
  40. 40. © 2019 Denim Group – All Rights Reserved Reporting • Know your audience(s) • Who are you consumers? • Security/risk management • Individual service owners/developers • Start with your ABOM to provide context 40
  41. 41. © 2019 Denim Group – All Rights Reserved Security/Risk Management • Risk = Impact x Likelihood • Likelihood is important in these complicated systems • DREAD • CVSS vX – Base + Environmental Metrics • Will often require a narrative • ”If A, then B, then C…” • Base concerns for exposure • Compliance • Service Level Agreements (SLAs) 41
  42. 42. © 2019 Denim Group – All Rights Reserved Service Owner/Developer • Why should/must I care? • How do I fix this? 42
  43. 43. © 2019 Denim Group – All Rights Reserved Tailoring to Your Requirements • Nobody has the resources to do everything they want • If everything is important then nothing is important • What services deal with the most critical data? • What components of the system expose the most risk? • Are you more concerned that a container might have a blank root password or that your login routine might have Cross Site Scripting (XSS) exposed? 43
  44. 44. © 2019 Denim Group – All Rights Reserved Prioritized Testing 44 • Dynamic testing of public-facing sites and services • That’s what most bad guys will see • Cloud configuration checks to identify potential unknown attack surface • Open S3 buckets, etc • Prioritize additional activities based on resources
  45. 45. © 2019 Denim Group – All Rights Reserved Tailoring to Your Requirements 45
  46. 46. © 2019 Denim Group – All Rights Reserved Decisions You Might Make • What’s the attack surface? • Definitely known: • Web front end • Chat server • Hosted MongoDB • Need to determine additional exposure: • Scan exposed network assets • Check cloud configuration 46
  47. 47. © 2019 Denim Group – All Rights Reserved Test Plan • Enumerate assets to establish ABOM • Cloud configuration check • Identify S3 buckets, gross IAM sins • Network scan of exposed (and owned) IPs • DAST scan of Web Front End • Maybe some manual penetration testing • DAST/API scan of Chat Server • Again maybe some manual penetration testing 47
  48. 48. © 2019 Denim Group – All Rights Reserved If You Have More Resources • More manual testing for Web Front End and Chat Server • DAST/API scans of User/Content/Location Services • SAST and manual code review for Web Front End, and User/Content/Location Services • Interior network scanning • Container vulnerability scanning for container images running User/Content/Location Services • Vendor security checks for hosted MongoDB 48
  49. 49. © 2019 Denim Group – All Rights Reserved Building a world where technology is trusted. @denimgroup www.denimgroup.com Dan Cornell @danielcornell www.denimgroup.com Questions and Answers

×