Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Making Security as Agile as Dev:
Adding DevOps and TDD to your security program
Matt Tesauro
OWASP San Antonio
March 2015
Who am I?
4 months with Pearson
Application Security Lead Engineer
Prior to Pearson
● Rackspace - Lead Engineer, Product S...
Who am I?
Other professional experience
● OWASP Live CD / OWASP WTE
o Project lead 2008 to present
o Over 300K downloads
o...
Making Security Agile
CI, CD, CD, TDD and API
CI == Continuous Integration
CD == Continuous Deployment
CD == Continuous Delivery
TDD == Test Dri...
• Cycle time for software is getting
shorter
• Continuous delivery is a goal
• Scanning windows are not viable
• First mov...
The Problem – or at least more problems
• Traditional software development left little time to test
• DevOps, Agile and Co...
• Automated software
testing
• Automated operational
infrastructure
• Automated security
testing
THE SOLUTION
Think like a developer
Sprints break software into little pieces…
• Break your testing into little pieces
• Use your threa...
Maximize what you’ve got
Make the most of your frameworks
•Embrace, understand and fill gaps where necessary
Make the best...
Under the constraints of DevOps, Continuous Deployment
Your testing has to be nimble
Dare I say…Agile
In TDD, you know you...
A time to morn...
• Securing Infrastructure
• Securing Apps and APIs
• Securing Code
Automate yourself into an agile state by...
Securing Infrastructure
Automating Infrastructure
• Declarative configuration language
• Plain-text configuration in source control
• Fully progra...
Most of these work like...
1. Ad Hoc
2. Local runs
3. Hosted/SaaS
4. Private Hosted Node
Node
Node
Node
Node
Node
Node
Nod...
Cookbooks, Stacks, Playbooks, ...
• Most have methods to
bundle / share
automation routines
• You will have to write
your ...
Grouping & Tagging
• Tagging your
servers applies
the required set of
automation
• A base set of for
all servers
• Each se...
Inspector – you need one
• For each group and/or tag
• Review the recipe, do a PR
• Hook provisioning for post deploy revi...
Agent – one mole to rule them all
• Add an agent to the standard deploy
• Read-only helps sell to SysAdmin
• Looks at the ...
Turn Vuln scanning on its head
• Add value for your ops teams
• Subscribe and parse vuln emails for key software
• Get thi...
Securing Apps and APIs
Findings directly to bug trackers
• PDFs are great, bugs are better
• Work with developer teams to submit bugs
• Security ...
For the reticent: nag, nag, nag
• Attach a SLA to each severity level for findings
• Remediation plan vs Fixed
• “Age” all...
Reports = Findings + Automation
• Consider markup for findings
• Markdown, Wiki Text, asciidoc
• Pandoc to convert to what...
Leverage existing consistencies
• Requires consistent (generally automated) input
• Find these and write some scripts
• Au...
Securing Code
Start with the developers
• Finding details have to be detailed enough to:
• Reproduce the issue after 6 months
• Allow QA...
Cherry pick what you look at
• Threat Models are your friends
• Focus on weak, unclear or suspicious areas
• Focus on conn...
No False Positive, period.
• If you can automate code review, you still must triage
• 1 false positive == 100 valid bugs
•...
Quiet is better then wrong
• Hire or befriend developers
• Need to speak their language, not security's
• Suggest requirem...
What is happening
at Pearson?
Say hello to my little friend...
The AppSec Pipeline
Key Features of AppSec Pipelines
• Designed for iterative improvement
• Provides a reusable path for AppSec activities to ...
Spending time optimizing anything
other than the critical resource
is an illusion.
Key Goals of AppSec Pipelines
• Optimize the critical resource - AppSec personnel
• Automate all the things that don’t req...
Pipeline - Intake
• “First Impression”
• Major categories of Intake
• Existing App
• New App
• Previously tested App
• App...
Pipeline – the Middle
• Inbound request triage
• Ala Carte App Sec
• Dynamic Testing
• Static Testing
• Re-Testing mitigat...
Pipeline – the End
• Source of truth for all AppSec activities
• ThreadFix is used to
• Dedup / Consolidate findings
• Nor...
Why we like AppSec Pipelines
• Allow us to have visibility into WIP
• Better understand/track/optimize flow of engagements...
Key Take Aways...
• Automate, automate, automate
• Look for “paper cuts” and fix those first
• Finding workflow
• Figure this out and standa...
The AppSec Pipeline
Change is here and more is coming...
"Whosoever desires constant
success must change his conduct
with the times."
— Niccol...
Questions?
Thank You
5 Stages of Grief
This agile thing is a fad...
Waterfall is the only way to produce
quality software...
5 Stages of Grief
There's no way I can test in that time
frame...
If I see another freaking sticky note...
5 Stages of Grief
Well, I think I can test some of it in
two days...
I guess I can test it after its deployed
to prod...
5 Stages of Grief
After that launch, I updated my
LinkedIn profile...
Game over man, GAME OVER...
(Thanks Aliens)
5 Stages of Grief
So when can you add a story to work
on that auth regression...
After reviewing your deployment
recipe, w...
Making security-agile matt-tesauro
Making security-agile matt-tesauro
Making security-agile matt-tesauro
Nächste SlideShare
Wird geladen in …5
×

Making security-agile matt-tesauro

Software development is happening faster then ever. Can your AppSec program keep up? This talk shows how an AppSec pipeline can help speed things up.

Making security-agile matt-tesauro

  1. 1. Making Security as Agile as Dev: Adding DevOps and TDD to your security program Matt Tesauro OWASP San Antonio March 2015
  2. 2. Who am I? 4 months with Pearson Application Security Lead Engineer Prior to Pearson ● Rackspace - Lead Engineer, Product Security ● AppSec consulting o VP Services, Praetorian o Consultant Trustwave’s Spiderlabs ● TEA - Senior Security Engineer ● DIR - Penetration Tester ● Texas A&M University o Systems Analyst, Sys Admin, Developer, DBA o Lecturer in MIS department ● Viatel - Internet App Developer
  3. 3. Who am I? Other professional experience ● OWASP Live CD / OWASP WTE o Project lead 2008 to present o Over 300K downloads o http://appseclive.org ● OWASP Foundation Board of Directors o International charity focused on improving the security of software ● Multiple speaking engagements internationally at AppSec, DHS, ISC2, … conferences ● Application Security Training internationally
  4. 4. Making Security Agile
  5. 5. CI, CD, CD, TDD and API CI == Continuous Integration CD == Continuous Deployment CD == Continuous Delivery TDD == Test Driven Development API == Application Programming Interface
  6. 6. • Cycle time for software is getting shorter • Continuous delivery is a goal • Scanning windows are not viable • First mover / first to market advantage The Problem
  7. 7. The Problem – or at least more problems • Traditional software development left little time to test • DevOps, Agile and Continuous Delivery squeeze those windows even more • New languages and programming methods aren’t making this better • Growth of interpreted languages with loose typing hurts static analysis efforts • Few automated tools to test APIs especially RESTful APIs • Little time for any testing, manual testing is doomed
  8. 8. • Automated software testing • Automated operational infrastructure • Automated security testing THE SOLUTION
  9. 9. Think like a developer Sprints break software into little pieces… • Break your testing into little pieces • Use your threat model to know the crucial bits to test Long and short running tests • Testing time drives testing frequency • Code for tests needs to be optimized Smoke test versus full regression test • Smoke test early and often • Full regression tests on regular intervals
  10. 10. Maximize what you’ve got Make the most of your frameworks •Embrace, understand and fill gaps where necessary Make the best use of your time… • Make tests easily repeatable • Make tests easy to understand • Make tests abstract and combine-able • Ala carte tests for mixing and matching • Think about the Unix pipe | and its power
  11. 11. Under the constraints of DevOps, Continuous Deployment Your testing has to be nimble Dare I say…Agile In TDD, you know your code works when the tests pass In TD(S), you know your app has met the baseline when the tests pass Test Driven Development Security
  12. 12. A time to morn...
  13. 13. • Securing Infrastructure • Securing Apps and APIs • Securing Code Automate yourself into an agile state by...
  14. 14. Securing Infrastructure
  15. 15. Automating Infrastructure • Declarative configuration language • Plain-text configuration in source control • Fully programmatic, no manual interactions
  16. 16. Most of these work like... 1. Ad Hoc 2. Local runs 3. Hosted/SaaS 4. Private Hosted Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Sys Admin The Mother Ship
  17. 17. Cookbooks, Stacks, Playbooks, ... • Most have methods to bundle / share automation routines • You will have to write your own / customize • Good place to spend security cycles -Merge patches upstream for extra points.
  18. 18. Grouping & Tagging • Tagging your servers applies the required set of automation • A base set of for all servers • Each server can have multiple tags • Map tags to security requirements Node Node Node Node DB Node Node Node Node Cache Node Node Node Node Web Apache Monitoring MySql Memcache Works for Clouds Too!
  19. 19. Inspector – you need one • For each group and/or tag • Review the recipe, do a PR • Hook provisioning for post deploy review • Focus on checking for code compliance -Not perfection, bare minimums • Can include multiple facets -Security, Scalability, Compliance • Vuln scanners – manual or auto • Jenkins Job + Lynis (open source)
  20. 20. Agent – one mole to rule them all • Add an agent to the standard deploy • Read-only helps sell to SysAdmin • Looks at the state of the system • Reports the state to the “mothership” • Add a dashboard to visualize state of infrastructure • Change policy, servers go red • Watch the board go green as patches roll-out • Roll your own or find a vendor Mozilla MIG
  21. 21. Turn Vuln scanning on its head • Add value for your ops teams • Subscribe and parse vuln emails for key software • Get this info during threat models or config mgmt • Provide an early warning and remove panic from software updates • Roll your own or find a vendor • Gmail + filters can work surprisingly well • Secunia VIM covers 40K+ products • Reverse the scan then report standard
  22. 22. Securing Apps and APIs
  23. 23. Findings directly to bug trackers • PDFs are great, bugs are better • Work with developer teams to submit bugs • Security category needs to exist • Bonus points if the bug tracker has an API • Security issues are now part of the normal work flow • Beware of death by backlog • Occasional security sprints • Learn how the team treats issues • ThreadFix is nice for metrics and pumping issues into issue trackers - http://code.google.com/p/threadfix/
  24. 24. For the reticent: nag, nag, nag • Attach a SLA to each severity level for findings • Remediation plan vs Fixed • “Age” all findings against these SLAs • Politely warn when SLA dates are close • Walk up the Org chart as things get older • Bonus points for dashboards and bug tracker APIs • Get management sold first
  25. 25. Reports = Findings + Automation • Consider markup for findings • Markdown, Wiki Text, asciidoc • Pandoc to convert to whatever • HTML, PDF, .doc, .odt, ... • Keep testers writing the least possible • Template and re-use boiler plate items • New finding == new template for next time • Web app to keep things consistent • Push or Pull from Threadfix via API
  26. 26. Leverage existing consistencies • Requires consistent (generally automated) input • Find these and write some scripts • Automate the drudgery • Examples: • Automate finding/bug submission • Automate report PDF generation • API documentation to basic testing harness • Sec tool output – combine and convert
  27. 27. Securing Code
  28. 28. Start with the developers • Finding details have to be detailed enough to: • Reproduce the issue after 6 months • Allow QA/QE to test the issue • Allow developers to find/fix the issue • Consider quick and dirty scripts to reproduce issue • Script to abuse an API • Web page of reflective XSS findings • Gauntlt - http://gauntlt.org/ • Once findings start flowing, look for training requests
  29. 29. Cherry pick what you look at • Threat Models are your friends • Focus on weak, unclear or suspicious areas • Focus on connections with external systems • Focus on format translations (XML to JSON) • When code changes in those areas, • Red flag it for review • Change +2 to +3 to before accepting pull request • Use search features in source code management • Start a list of problematic methods, calls, etc
  30. 30. No False Positive, period. • If you can automate code review, you still must triage • 1 false positive == 100 valid bugs • If results aren't actionable, fail • Stick to diff analysis • Threat Modeling + “Scary Parts” + Code diffs == Quick triage of code changes • Automate where you can, iterate until you're happy • Need to build cred points with the dev teams
  31. 31. Quiet is better then wrong • Hire or befriend developers • Need to speak their language, not security's • Suggest requirements not implementation • Mitigation suggestions either generic or in the language the app is written in • Remember: Fast deploys also means fast fixes • Trying to shrink any vuln window not eliminate • Be prepared to retest / verify fix quickly
  32. 32. What is happening at Pearson?
  33. 33. Say hello to my little friend...
  34. 34. The AppSec Pipeline
  35. 35. Key Features of AppSec Pipelines • Designed for iterative improvement • Provides a reusable path for AppSec activities to follow • Provides a consistent process for both the team and our constituency • One way flow with well-defined states • Relies heavily on automation • Has the ability to grow in functionality organically over time • Gracefully interconnects with the development process
  36. 36. Spending time optimizing anything other than the critical resource is an illusion.
  37. 37. Key Goals of AppSec Pipelines • Optimize the critical resource - AppSec personnel • Automate all the things that don’t require a human brain • Drive up consistency • Increase tracking of work status • Increase flow through the system • Increase visibility and metrics • Reduce any dev team impedance with application security
  38. 38. Pipeline - Intake • “First Impression” • Major categories of Intake • Existing App • New App • Previously tested App • App to re-test findings • Key Concepts • Ask for data about Apps only once • Have data reviewed when an App returns • Adapt data collected based on broad categories of Apps
  39. 39. Pipeline – the Middle • Inbound request triage • Ala Carte App Sec • Dynamic Testing • Static Testing • Re-Testing mitigated findings • Mix and match based on risk • Key Concepts • Activities can be run in parallel • Automation on setup, configuration, data export • Focus on customization rather than setup
  40. 40. Pipeline – the End • Source of truth for all AppSec activities • ThreadFix is used to • Dedup / Consolidate findings • Normalize scanner data • Generate Metrics • Push issues to bug trackers • Report and metrics automation • REST + tfclient • Source of many touch points with external teams
  41. 41. Why we like AppSec Pipelines • Allow us to have visibility into WIP • Better understand/track/optimize flow of engagements • Average static test takes ... • Great increase in consistency • Easier re-allocation of engagements between staff • Each step has a well defined interface • Knowing who has what allows for more informed “cost of switching” conversations • Flexible enough for a range of skills and app maturity
  42. 42. Key Take Aways...
  43. 43. • Automate, automate, automate • Look for “paper cuts” and fix those first • Finding workflow • Figure this out and standardize / optimize • Create systems which can grow organically • App is never done, its just created to easily be added to over time • Finding blocks become templates for next time • Learn to talk “dev”
  44. 44. The AppSec Pipeline
  45. 45. Change is here and more is coming... "Whosoever desires constant success must change his conduct with the times." — Niccolo Machiavelli
  46. 46. Questions? Thank You
  47. 47. 5 Stages of Grief This agile thing is a fad... Waterfall is the only way to produce quality software...
  48. 48. 5 Stages of Grief There's no way I can test in that time frame... If I see another freaking sticky note...
  49. 49. 5 Stages of Grief Well, I think I can test some of it in two days... I guess I can test it after its deployed to prod...
  50. 50. 5 Stages of Grief After that launch, I updated my LinkedIn profile... Game over man, GAME OVER... (Thanks Aliens)
  51. 51. 5 Stages of Grief So when can you add a story to work on that auth regression... After reviewing your deployment recipe, we filed a pull request to fix...

×