Continuous Application Security Testing Presented by: - - PDF document

▶
continuous application security testing
SMART_READER_LITE
LIVE PREVIEW

Continuous Application Security Testing Presented by: - - PDF document

Dec 19, 2022 258 likes •306 views

W14 Security Testing Wednesday, October 23rd, 2019 3:00 PM Continuous Application Security Testing Presented by: Josh Gibbs

slide-1
SLIDE 1

¡ ¡ W14 ¡

Security ¡Testing ¡ Wednesday, ¡October ¡23rd, ¡2019 ¡3:00 ¡PM ¡ ¡ ¡ ¡ ¡

Continuous ¡Application ¡Security ¡Testing ¡ ¡

Presented ¡by: ¡ ¡ ¡

¡ Josh ¡Gibbs ¡

¡ Contrast ¡Security ¡ ¡

Brought ¡to ¡you ¡by: ¡ ¡ ¡ ¡

¡

¡

¡ ¡

888-­‑-­‑-­‑268-­‑-­‑-­‑8770 ¡·√·√ ¡904-­‑-­‑-­‑278-­‑-­‑-­‑0524 ¡-­‑ ¡info@techwell.com ¡-­‑ ¡http://www.starcanada.techwell.com/ ¡ ¡ ¡

¡

¡ ¡ ¡

¡

slide-2
SLIDE 2

Josh ¡Gibbs ¡

¡ Josh ¡Gibbs ¡is ¡a ¡senior ¡customer ¡success ¡manager ¡at ¡Contrast ¡Security, ¡where ¡he ¡ helps ¡companies ¡build ¡security ¡into ¡their ¡applications. ¡Prior ¡to ¡his ¡current ¡role, ¡Josh ¡ led ¡the ¡security ¡testing ¡team ¡at ¡a ¡major ¡cloud ¡hosting ¡provider. ¡He ¡has ¡previously ¡ worked ¡in ¡development ¡and ¡security ¡roles ¡within ¡the ¡marketing ¡technology ¡and ¡ finance ¡industries. ¡In ¡his ¡spare ¡time, ¡Josh ¡enjoys ¡gardening, ¡barbecuing, ¡and ¡ spending ¡time ¡with ¡his ¡family. ¡ ¡

slide-3
SLIDE 3

Continuous Application Security Testing

Presented by Josh Gibbs @appsecjosh

Security Impacts of CI/CD

  • Automated tests and reliable deployments simplify fixing vulnerabilities.
  • Shifting left can move decisions from managers to engineers.
  • More data is not always better data. Beware of analysis paralysis.
  • Vulnerability scans and penetration tests may appear less effective when vulnerabilities are fixed earlier.

Business Logic Vulnerabilities

  • Typically found by matching patterns, analyzing data flows, and injecting values
  • Remediation via code changes
  • Mitigate with application layer controls (WAF/RASP)

Platform Vulnerabilities

  • Typically found by reviewing configuration, checking lists of vulnerable versions, and replaying common attacks
  • Remediation via patching
  • Mitigate with network layer and operating system controls (firewall, user permissions, etc.)

Tools at a Glance

Static Analysis Dynamic Analysis Interactive Analysis Approach White Box Black Box Gray Box Artifact Assessed Code Running App Code & Running App Notable Limitations Language support, Lack of visibility to entire system Application state, API’s, Client-rendered pages Language support, attack types detected Time to Run Minutes to Days Hours to Weeks Seconds to Days Precision Specific line of code File or Page/Route Specific line of code Favors Coverage, Speed Exploitable flaws Exploitable flaws, Speed At the expense of False positives Speed, Coverage False negatives Note: This table is a broad generalization of tools to help plan where to use tools in pipelines.

Continuous Security Activities

Design Code Review Package Validate Deploy Development Activities Story Definition Programming + Unit Tests Code Review Compile + Integration Tests System Tests Health Checks + Smoke Test Security Activities Threat Modeling Secure Coding + Unit Tests Static Analysis Library Checks Interactive Analysis Security Smoke Test

slide-4
SLIDE 4

Suggestions for Improving Security Testing

1. Start with threat modeling to focus effort on risks relevant to your system.

  • Store the threat model with your engineering documentation.
  • Review the threat model periodically, and update it as the attack surface changes.
  • If a security incident occurs, highlight the attacker’s actions in the threat model.

2. Choose feedback methods that emphasize the action you want.

  • Archival: PDF reports & e-mails
  • Manager’s attention: Dashboards, e-mailed spreadsheet
  • Fix before deploying: build failure, chat notification, pull request status/comment

3. Create an internal “how-to” guide for what to do when fixing a security bug.

  • OWASP is a great reference.

4. Plan to triage existing, but previously unknown, vulnerabilities when introducing new tools.

  • Consider first results to be “security backlog.”
  • Establish policy of “No new security issues.”

5. Define success measures that relate to business objectives.

  • Cost (time and fees) of unplanned security events
  • Time to perform security assessment
  • Time to fix vulnerabilities (total age by severity)
  • Number of vulnerabilities detected and released knowingly.

6. Create post-deployment security health checks.

  • TLS configuration (ciphers, certificate validity)
  • HTTP security headers

7. Tag security tests in unit, integration, system test suites.

  • Authentication, authorization, session management
  • User registration, password recovery
  • Financial transactions - checkout, coupon redemption

8. Include abuse cases in user stories.

  • “As an administrator, I should not be able to view a user’s payment card data.”

9. Automatically collect and archive evidence of compliance.

  • Git logs
  • Test results
  • Pull request discussions
  • Deployment history
  • 10. Be specific with penetration testers.
  • “This is everything we know to be running. Verify that we have no other exposures.”
  • “We just started running our apps in containers. Can you try to compromise the host OS from a container?”

Additional Resources

  • OWASP Application Security Verification Standard (ASVS)

https://github.com/OWASP/ASVS

  • DevOps Audit Defense Toolkit

http://images.itrevolution.com/documents/DevOps_Audit_Defense_Toolkit_v1.0.pdf

  • Verizon Data Breach Investigations Report

https://enterprise.verizon.com/resources/reports/dbir/

  • OWASP Cheat Sheet Series

https://cheatsheetseries.owasp.org/