Software Security Initiative CapabilitiesWhere Do I Begin?

January 26, 2016

OWASP AppSec California

Copyright © 2016, Cigital and/or its affiliates. All rights reserved. | Cigital Confidential Restricted

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

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

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

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.

When do you do these three activities?

Requirementsand Use Cases

Architectureand Design

Test Plans

Code Test and

Test Results

Feedback fromthe field

AbuseCases

SecurityRequirements

RiskAnalysis

ExternalReview

Risk-BasedSecurity Tests

Code Review(Tools)

RiskAnalysis

PenetrationTesting

SecurityOperations

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, …)

…

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

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 …

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

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

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

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

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

Complementary defect discovery techniques

Pen-Testing Code Review

Design Review

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

QUESTIONS?

17