45
Agile Security Getting It Right From the Start Nick Murison Managing Consultant [email protected] Twitter: @nickmurison

Agile security - Getting it right from the start

  • Upload
    cigital

  • View
    490

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Agile security - Getting it right from the start

Agile SecurityGetting It Right From the Start

Nick MurisonManaging [email protected] Twitter: @nickmurison

Page 2: Agile security - Getting it right from the start

The Challenge• Idea Prototype Reality

When do we put security into the design?

Page 3: Agile security - Getting it right from the start

In the old days… waterfallRequirements Gathering

Architecture and Design

Code and Development

Testing

Deployment

SecurityGate

SecurityGate

SecurityGate

SecurityGate

Page 4: Agile security - Getting it right from the start

ModernSoftwareDevelopment

The Agile Manifesto is a set of principles, not a rigid methodology. There are many Agile method-ologies, including Scrum and Kanban.

Page 5: Agile security - Getting it right from the start

Problems Start-ups Face

“Security is hard”It’s not easy, but it’s easier than ever.

Use secure frameworks. Don’t disable their sensible defaults.

“We’ll secure that later, just get it working”“Later” never comes

Software isn’t released; it escapes“What could possibly go wrong?”

Lots. You’re creating something that has never existed before

Attackers have way more resources than you do

Page 6: Agile security - Getting it right from the start

Common Security Design Flaws• Baby Duck Authentication

• First thing I “see” must be my mother• Download instructions, firmware update, admin

mode, whatever• Kung-Fu Grip

• Press a magic key physical sequence to get factory reset

• Perfect for resetting/bypassing security• Secret Handshake

• Exchange special message, username, password, etc.

• Often used for maintenance, admin, debugging• Usually abused

Page 7: Agile security - Getting it right from the start

7

• No little numbers (e.g., Acct=482, Device=1).• Just use GUIDs all the time.• If it’s human-readable, it’s

probably easy to attack.• You MUST rate-limit

everything• How many Xs per Y?

Request/hour, signups/day, emails/human, etc.

• Plan for regular upgrades• Your platforms, your hardware,

your dev tools, your libraries• Expect software to be

abandoned, too (open source, etc.)

• The backwards compatibility problem is real• If you didn’t secure version 1,

will you abandon those users in version 2?

Seriously Important Security for Start-ups

Page 8: Agile security - Getting it right from the start

Cigital’s “Agile Security Manifesto”• Rely on good developers and testers over security specialists

• Implement secure features over adding security features afterwards

• Continuously improve security over completely changing processes

• Focus on fixing software over finding bugs

• www.cigital.com -> Resources -> eBooks

Page 9: Agile security - Getting it right from the start

Plann

in

g

Evaluation

Implementati

on

Testi

ng

New Needs

Deployment

Modern Software Development

Page 10: Agile security - Getting it right from the start

Plann

in

g

Evaluation

Implementati

on

Testi

ng

New Needs

Deployment

Security User Stories

Secure Code

Review

Security Testing

Penetration Testing

Secure Design Review

Modern Software Development with Security

Page 11: Agile security - Getting it right from the start

Security User Stories

Page 12: Agile security - Getting it right from the start

1212

Adding Security User Stories

As a fraudster, I want to see the details of an

order that is not my own so that I can learn

another person’s private information.

As a customer, I want to track the shipment of my order so that I know when it will arrive.

User Story Security Story

Page 13: Agile security - Getting it right from the start

1313

“Bad Guys” in Security User Stories

• Competitor• Misbehaving customer• Hacker• Journalist• Vandal• Disgruntled employee

• Learn private information• Commit a fraudulent

transaction• Damage the company’s

brand• Prevent people from

doing their job• Sell valuable information

“Users” Goals

Page 14: Agile security - Getting it right from the start

1414

“Good Guys” in Security User Stories

• Auditor• Customer Service Rep• System Operator• Well-behaved user• Manager

• Verify a transaction• Determine some

important information• Report on error

conditions• Display the status of

something

“Users” Goals

Page 15: Agile security - Getting it right from the start

15

Acceptance Criterion 1• Given that the user is logged in

• And the session is valid• And the request is for an order that

does not belong to the logged-in user,• When the user requests the details• Then display an error message

• And ensure the user is no longer logged in

• And log an error to the application log.

Acceptance Criterion 2• Given that the user is not logged in

• And the request is for an order• When the user requests the details• Then display an error message

• And ensure the user is not logged in• And log an error to the application log.

15

Security User StoriesAs a misbehaving customer,I want to see the details of an order that is not mineSo that I can learn private information of another person

Page 16: Agile security - Getting it right from the start

Software Architecture

Page 17: Agile security - Getting it right from the start

Bugs and Flaws

Architectural flawsImplementation bugs

misuse of cryptography duplicated codemissing authorization checks

SQL injectioncross-site scripting

buffer overflow

50%50%

Page 18: Agile security - Getting it right from the start

18

Bugs versus Flaws

• Localised• Found in the code• Fixed in the code• Design remains the

same

• General• Design needs

adjustment• Code could be right,

but problem would still occur

Bugs Flaws

Hackers Don’t Care!

Page 19: Agile security - Getting it right from the start

We Care About Bugs Versus FlawsBugs Flaws

Find• IDE Tools• Code scanning• Peer review• Compiler tools

• Architecture review• Design review

Fix• Change the code• Use a 3rd party

library• Change the design• Re-implement new code

Page 20: Agile security - Getting it right from the start

20

Key Components of a Threat Model• Threat Modeling outlines a systematic way to

enumerate and visualize the potential threats to a system.

• Key components are:• Model of the system (or protocol, etc.)• Traceability Matrix• Optionally:

• Misuse/Abuse cases• Security test strategy• Security requirements

Page 21: Agile security - Getting it right from the start

21

Example Threat Model

Page 22: Agile security - Getting it right from the start

Traceability Matrix“A threat agent, trying to compromise some asset, using an attack, interacting via attack surface, in order to achieve attack goal, having impact, mitigated to an acceptable risk level by control.”

22

Threat Agent

Asset Attack Attack Surface Attack Goal Impact Controls

Page 23: Agile security - Getting it right from the start

23

Threat Modeling Improves Security• Targeted pen tests• Targeted code reviews• Discover new things

• Design flaws• Connections that were not considered part of the normal

test strategy

Page 24: Agile security - Getting it right from the start

Code Review“The other 50%”

Page 25: Agile security - Getting it right from the start

25

Types of Code Review• Tools that scan like compilers• Tools that search for key words• Tools that check platform configuration

• People reviewing code• People reviewing tool output

Page 26: Agile security - Getting it right from the start

26

Code Review

Peer Review

IDE Plugi

n

Repository

Scan

Nightly

Scans

Developers DevelopmentEnvironment

CodeRepositor

y

Build Server

Page 27: Agile security - Getting it right from the start

27

Choices for Code ReviewYour Developers Partners / Vendors

Peer Review Train them Make it verifiable part of the SDLC

IDE Plugin Buy it, use it Require it, perhaps buy itRepository Periodically Keep copy or master

repository, scan itNightly Builds Do it Require the unfiltered

outputWhatever You Do:Track the issues yourself. Get exposure to the raw issues and follow them.

Page 28: Agile security - Getting it right from the start

28

Code Review is Hard• Code review is hard when:

• Teams first start• Tools are not configured well

• Determining validity is hard• False positive• False negative• Root cause analysis of true positive

• Determining priority is hard• Impact• Likelihood

Page 29: Agile security - Getting it right from the start

Security Testing

Page 30: Agile security - Getting it right from the start

3030

Testing

• Your advocate• Full, systematic coverage

of all user journeys• Relatively complete test

data• Reasonable domain

knowledge• Lots of time

• Independent• Risk-based coverage of a

fraction of possible journeys

• Typically incomplete test data

• Minimal domain knowledge• Time budgeted

Functional Testers Penetration Testers

Page 31: Agile security - Getting it right from the start

31

1. Capture test data from penetration tests•Give to regression testers•Duplicate their results• Test every subsequent

release2. Track Defects

•Use the same defect tracker the devs use

3. Pinpoint training needs based on security results

•Advanced framework features

•Cryptography•Defensive Programming

31

Making the Most of Security Testing

Page 32: Agile security - Getting it right from the start

So where to start?

Page 33: Agile security - Getting it right from the start

BSIMM

Page 34: Agile security - Getting it right from the start

Building BSIMM (2008)• BIG idea: Build a maturity model from actual data gathered

from 9 well-known large-scale software security initiatives.• Create a software security framework.• Interview 9 firms in-person.• Discover 110 activities through observation (1 removed, 3 added

later).• Organize the activities in 3 levels.• Build a scorecard.

• The model has been validated with datafrom 129 firms (95 in BSIMM7).

• There is no special snowflake.

Page 35: Agile security - Getting it right from the start

BSIMM: Software Security Measurement• 129 firms measured (data freshness)• BSIMM7 = data from 95 real initiatives• 290 distinct measurements over time• 30 over time (one firm 5 times)• McGraw, Migues, and West

Page 36: Agile security - Getting it right from the start

95 Firms in BSIMM7 Community

Page 37: Agile security - Getting it right from the start

Monkeys Eat Bananas• BSIMM is not about good or

bad ways to eat bananas or banana best practices.

• BSIMM is about observations.

• BSIMM is descriptive, not prescriptive.

• BSIMM describes and measures multiple prescriptive approaches.

Page 38: Agile security - Getting it right from the start

A Software Security Framework

See informIT article on BSIMM website http://bsimm.com

4 Domains 12 Practices

Page 39: Agile security - Getting it right from the start
Page 40: Agile security - Getting it right from the start

Earth (95)

Page 41: Agile security - Getting it right from the start

BSIMM7 as a Measuring Stick

Page 42: Agile security - Getting it right from the start

BSIMM7 Results• Top 12 activities

• purple = good?• red = bad?

• “Blue shift” = practices to emphasize

Page 43: Agile security - Getting it right from the start

Improvement Over Time

• 30 firms measured twice (an average of 25 months apart)

• We know how firms improve• An average of 34.6%

activity increase

Page 44: Agile security - Getting it right from the start

Using the BSIMM• BSIMM7 released October 2016 under Creative Commons.

• http://bsimm.com• Download the document• Look at the most common activities• Get ideas about what activities make the most sense for your

organisation to implement

• BSIMM is a yardstick.• Use it to see where you stand.• Use it to figure out what your peers do.• Use it to figure out what to do next!

Page 45: Agile security - Getting it right from the start

The best time to plant an oak tree was twenty years ago.

The next best time is now.—Ancient Proverb

©2005 Stan Shebs

Nick [email protected]: @nickmurison