Application security in a hurry webinar

149 views

Published on

In this webinar, 451 Research Director, Wendy Nather and NT OBJECTives co-CEO and CTO, Dan Kuykendall discuss Wendy and Dan discuss how to scale your application security program to address hundreds or thousands of applications and how to avoid the common technology and process pitfalls.
More info and recording: http://www.ntobjectives.com/go/scaling-web-application-security-scanning

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
149
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Application security in a hurry webinar

  1. 1. Securing in a HurryWhen You’ve Waited Until the Last Minute to Get Your Application Audit On May 2nd, 2012 www.NTOBJECTives.com
  2. 2. Todays Presenters Wendy Nather Research Director Dan Kuykendall Co-CEO & Chief Technology Officer
  3. 3. Securing in a Hurry
  4. 4. Ready, set … scan! (or) The fire drill begins!• You’re already under attack and you need to know how many other holes you have that could be exploited• You forgot about that part of PCI-DSS and the QSA arrives in a week• You need to perform due diligence for a merger or acquisition• Your CEO switched from Talls to Ventis
  5. 5. What do you need to know first?• Where the applications live – all of them ‒ Very few have a good/comprehensive list• Which ones you’ll be allowed to scan• Who to contact when something goes wrong• Are QA/Staging environments available ‒ Better to test against non-production when possible• What you’ll do once you find things ‒ How much can you fix? ‒ What can you block with a WAF?
  6. 6. Who are you outrunning?Script kiddies ‒ Lots of them with much more free time than you + Limited mostly to cheap/free tools and scripts  Limited business logic, mostly SQL/XSS type issuesSmart hackers with targeted attacks ‒ More skilled and with more tools and manual know how ‒ Focus on business logic flaws + Time (if you’re lucky), requires more time to find issuesInternal threats ‒ Have inside knowledge and access to resources ‒ More opportunity to accidentally find weaknesses + Can be punished when caught + Not usually the most skilled hackers
  7. 7. How sure do you need to be?• Automated vs. manual pen-testing ‒ Technology considerations ‒ Either or Both?• Checking for logic flaws in most critical applications ‒ Hint: this is going to take a lot longer• Decide how far down the rabbit hole you’re going to go ‒ How important is it to know the worst case for each vulnerability being exploited• False positives... Oh yes, there will be some
  8. 8. How sure do you need to be?• Automated vs. manual pen-testing ‒ Technology considerations ‒ Either or Both?• Checking for logic flaws in most critical applications ‒ Hint: this is going to take a lot longer• Decide how far down the rabbit hole you’re going to go ‒ How important is it to know the worst case for each vulnerability being exploited• False positives... Oh yes, there will be some
  9. 9. Automated vs. manual pen-testing Technology Considerations • Types of scanners • Comprehensive parameter checking • Technologies being scanned ‒ JavaScript / AJAX ‒ Mobile ‒ Thicker Client (Flash & Java applets) ‒ Web services • Reporting & verification • WAF/IPS Integration • SaaS vs. software
  10. 10. Automated vs. manual pen-testingAutomated + Not affected by tedious activity, will check every input + Repeatable & scalable ‒ Cannot check for certain types of vulns; business logic flaws ‒ Cannot make decisions based on contentManual pen-testing + Creative, understands content to make leaps of logic + Can perform all possible attacks ‒ Will only "spot check" ▪ 10 inputs x 200 payloads = 2000 attacks x 100 pages = 200,000 attacks ‒ Hard/impossible to scaleCombination (Ideal in most cases) + Automate mundane and repeatable aspects to get scalability and cost reductions + Use humans to test the aspects that require deductive reasoning based on logic
  11. 11. How sure do you need to be?• Automated vs. Manual pen-testing ‒ Technology considerations ‒ Either or Both?• Checking for logic flaws in most critical applications ‒ Hint: this is going to take a lot longer• Decide how far down the rabbit hole you’re going to go ‒ How important is it to know the worst case for each vulnerability being exploited• False positives... Oh yes, there will be some
  12. 12. How sure do you need to be?• Automated vs. Manual pen-testing ‒ Technology considerations ‒ Either or Both?• Checking for logic flaws in most critical applications ‒ Hint: this is going to take a lot longer• Decide how far down the rabbit hole you’re going to go ‒ How important is it to know the worst case for each vulnerability being exploited• False positives... Oh yes, there will be some
  13. 13. How sure do you need to be?• Automated vs. Manual pen-testing ‒ Technology considerations ‒ Either or Both?• Checking for logic flaws in most critical applications ‒ Hint: this is going to take a lot longer• Decide how far down the rabbit hole you’re going to go ‒ How important is it to know the worst case for each vulnerability being exploited• False positives... Oh yes, there will be some
  14. 14. Oh yes, there will be false positives• Is vendor verification available?• You will waste time trying to convince someone that they’re valid• You will waste time and lose credibility that you may need for a real vulnerability later ‒ Cry wolf scenario• Separating vulnerabilities from acceptable risk or intended behavior ‒ e.g.. content manager that needs to allow JavaScript in content submissions
  15. 15. Oh yes, there will be false positives• Is vendor verification available?• You will waste time trying to convince someone that they’re valid• You will waste time and lose credibility that you may need for a real vulnerability later ‒ Cry wolf scenario• Separating vulnerabilities from acceptable risk or intended behavior ‒ e.g.. content manager that needs to allow JavaScript in content submissions
  16. 16. Oh yes, there will be false positives• Is vendor verification available?• You will waste time trying to convince someone that they’re valid• You will waste time and lose credibility that you may need for a real vulnerability later ‒ Cry wolf scenario• Separating vulnerabilities from acceptable risk or intended behavior ‒ e.g.. content manager that needs to allow JavaScript in content submissions
  17. 17. Oh yes, there will be false positives• Is vendor verification available?• You will waste time trying to convince someone that they’re valid• You will waste time and lose credibility that you may need for a real vulnerability later ‒ Cry wolf scenario• Separating vulnerabilities from acceptable risk or intended behavior ‒ e.g.. content manager that needs to allow JavaScript in content submissions
  18. 18. Oh yes, there will be false positives• Is vendor verification available?• You will waste time trying to convince someone that they’re valid• You will waste time and lose credibility that you may need for a real vulnerability later ‒ Cry wolf scenario• Separating vulnerabilities from acceptable risk or intended behavior ‒ e.g.. content manager that needs to allow JavaScript in content submissions
  19. 19. Preparing for battle• Set up a pipeline for the results ‒ Developers, sysadmins, project managers, QA• Make sure the scanner can reach all the apps ‒ Set up credentials, roles for widest coverage• Determine maximum scanning rate ‒ Server connection limits ‒ Problems when vhosting websites ‒ Enforcing concurrent scanning limits• Warn the operations team ‒ It’s about to get noisy in here ‒ You may want to mute the logging alerts ‒ Disable automatic routines that report hacking activity to ISP• Get emergency contact numbers for both sides
  20. 20. Questions you need answered first• How target rich is your environment? ‒ How many applications have vulnerabilities• Who can exploit the vulnerabilities ? ‒ e.g.. everyone, intranet only, auth required, verified accounts• How easy to discover? ‒ Easy to find SQL/XSS type issues vs. business logic issues• How hard to get fixed in code?• How much residual risk? ‒ Decide with your management what you’ll be comfortable with
  21. 21. When you’re in a target-rich environment… How do you prioritize? ‒ Largest number of vulnerabilities? ‒ "Most important" sites? ‒ “Most common” vulnerabilities? ‒ Most critical applications? ▪ Remember, lots of breaches happen through non- critical apps ‒ Whatever you can fix first? ‒ Whatever has the most shared code? ‒ Whatever the WAF can’t block?
  22. 22. Questions you need answered first• How target rich is your environment? ‒ How many applications have vulnerabilities• Who can exploit the vulnerabilities ? ‒ e.g.. intranet only, auth required, verified accounts• How easy to discover? ‒ Easy to find SQL/XSS type issues vs. business logic issues• How hard to get fixed in code?• How much residual risk? ‒ Decide with your management what you’ll be comfortable with
  23. 23. Questions you need answered first• How target rich is your environment? ‒ How many applications have vulnerabilities• Who can exploit the vulnerabilities ? ‒ e.g.. intranet only, auth required, verified accounts• How easy to discover? ‒ Easy to find SQL/XSS type issues vs. business logic issues• How hard to get fixed in code?• How much residual risk? ‒ Decide with your management what you’ll be comfortable with
  24. 24. Questions you need answered first• How target rich is your environment? ‒ How many applications have vulnerabilities• Who can exploit the vulnerabilities ? ‒ e.g.. intranet only, auth required, verified accounts• How easy to discover? ‒ Easy to find SQL/XSS type issues vs. business logic issues• How hard to get fixed in code?• How much residual risk? ‒ Decide with your management what you’ll be comfortable with
  25. 25. How hard to get fixed in code?• Are developers still available?• In-house or outsourced?• Is application still in active development?• When is next planned release?• Amount of time/process for standard/required QA verification?• Is WAF/IPS filter an option for quick and temporary protection against exploit?
  26. 26. Questions you need answered first• How target rich is your environment? ‒ How many applications have vulnerabilities• Who can exploit the vulnerabilities ? ‒ e.g.. intranet only, auth required, verified accounts• How easy to discover? ‒ Easy to find SQL/XSS type issues vs. business logic issues• How hard to get fixed in code?• How much residual risk? ‒ Decide with your management what you’ll be comfortable with
  27. 27. Good job, now let’s do this again!• Was this a one time event? • Usually once this is performed, management wants to see it again• How frequently will scanning need to be performed?• Re-scanning included in cost?
  28. 28. NT OBJECTives, Inc.• Dedicated to application security > 10+ years• Software, Services & SaaS ‒ NTOSpider: Dynamic Application Scanning Technology (DAST) ‒ NTOEnterprise: Enterprise web portal interface to manage scanning activity, access controls & report storage & access ‒ NTOSpider On-Demand: SaaS based on NTOEnterprise ‒ NTODefend: WAF/IPS integration tool to generate filters from scan results
  29. 29. Discussion & contact information Wendy Nather Research Director @451wendy http://idoneous-security.blogspot.com/ Dan Kuykendall Co-CEO & CTO @dan_kuykendall http://manvswebapp.com
  30. 30. Securing in a Hurry Questions & Discussion www.NTOBJECTives.com

×