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.

Software Security Initiative Capabilities: Where Do I Begin?


Published on

Where to begin your software security initiative including defect discovery, secure SDLC, vendor management and more.

Published in: Software
  • Be the first to comment

Software Security Initiative Capabilities: Where Do I Begin?

  1. 1. Software Security Initiative Capabilities Where Do I Begin? January 26, 2016 OWASP AppSec California Copyright © 2016, Cigital and/or its affiliates. All rights reserved. | Cigital Confidential Restricted
  2. 2. Squashing a few myths Assuming you want to deliver secure software… • An SSI is optional • My company is too small to have an SSI • An SSI will negatively impact our ability to quickly deliver <whatever it is you deliver> … or ... • We can’t have an SSI, we’re a DevOps/Agile/whatever shop
  3. 3. SSI capabilities • Secure SDLC with Gates • Satellite • Metrics • Portfolio Management • Policy and Standards • Vendor Management • Defect Discovery – Design • Defect Discovery – Fuzzing • Defect Discovery – Penetration Testing • Defect Discovery – Quality Assurance • Defect Discovery – Code Review • Defect Discovery – Research • Defect Management • Attack Intelligence • Open Source Management • Risk & Compliance • Secure by Design • SSG Outreach • Competency Management • IT Operations
  4. 4. Why have an SSI? • An SSI is really about preventing defects from ever occurring • Defect discovery is just a common place to start • Risk = Likelihood x Impact • Likelihood and Impact require knowledge of how the defect works and what components are affected • And that requires defect identification
  5. 5. Three common defect discovery techniques • Penetration testing • Code review focusing on software security • Design review focusing on software security Many SSIs get started by doing one of these activities.
  6. 6. When do you do these three activities?  Requirements and Use Cases  Architecture and Design  Test Plans  Code  Test and Test Results  Feedback from the field Abuse Cases Security Requirements Risk Analysis External Review Risk-Based Security Tests Code Review (Tools) Risk Analysis Penetration Testing Security Operations
  7. 7. Penetration test – What do we know? • A great deal of published material on attacks that work(ed) • We know what to try again • Testing driven by attributes of system (type, data, business, …) …
  8. 8. Penetration test – How? • Tool-driven • Very mature space • Many factors to consider – cost, capability of tool, feature set, customizability, deployment options, … • People-driven (outsourced) • Very mature space • Many factors to consider – cost, scalability, quality, trust, logistics, … • People-driven (in-house) • Hard to find, harder to keep, impossible to scale
  9. 9. Secure code review – What do we know? • SCR ≠ CR • Checklists for “things to look for” or “things to avoid” • E.g., information about dangerous APIs • Some frameworks publish secure coding guidelines • Guidance driven by language and/or framework and/or platform and/or …
  10. 10. Secure code review – How? • Tool-driven • Very mature • Many factors to consider – cost, capability of tool, feature set, languages supported, customizability, deployment options, … • People-driven • Inconsistent results – even the same person on a different day • Checklists can help but results will vary … a lot
  11. 11. Secure design review – What do we know? • AKA Threat Modeling • Analysis influenced by many factors • Type of system (web, mobile, PC, etc.) • Frameworks used • Interactions with external entities • Internal risk rating of system • This can be tricky to teach • Not everyone can do this
  12. 12. Secure design review – How? • Tool-driven • There is no tool-only option – at least none that I know of • Meaning tools don’t read artifacts you already created • You do the design review with a tool; or in a manual fashion • Very few choices compared to PT and SCR tools • People-driven • All SMEs are not created equal • People still have bad days
  13. 13. General comments about using tools The good… • I can do anything I have been programmed to do • If you teach me what to look for, I will look for it • If I have enough resources ... if there’s no bugs in my code ... The not so good... • I can only do what I have been programmed to do • I will never do anything new unless you teach me how to do it
  14. 14. General comments about using people The good… • Hard to replace the human brain • We can think outside the box • We all think differently The not so good… • We are not machines • We do not perform at the same level EVERY day • We all think differently so different results may be perfectly normal
  15. 15. Complementary defect discovery techniques Pen-Testing Code Review Design Review
  16. 16. Remember … This is just the beginning • Defect discovery covers more than the 3 techniques we talked about • Defect discovery is just a part of an SSI • You also need • the Secure SDLC for governance and context • the SDLC out-reach so everyone knows what to do • the competency management so everyone can do what they need to do • the vendor management to control risk with 3rd-party software and technology • and so on for the rest of the capabilities
  17. 17. QUESTIONS? 17