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

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Complementary defect discovery techniques
Pen-Testing Code Review
Design Review

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. QUESTIONS?
17