owasp lascon 2015 - agile security, the fails noboty told you about

Post on 22-Jan-2018

315 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

The Storyteller

Daniel Liber - R&D Security Leader• Security program management• Product security SDLC

~10 years of experience• Research, consulting, PT, engineering

CyberArk: Privileged Account Security

…A Quote

“Success is stumbling from failure to failure with no loss of enthusiasm.”

(Winston Churchill)

Chapters

• Agile, a reminder• Integrating traditional security with Agile• Hidden risks in the process• Collaboration and delegation of security

tasks• Increasing visibility and efficiency

And so, our story begins…

Let’s Talk Agile.

Individuals and interactions overprocesses and tools

Working software overcomprehensive documentation

Customer collaboration overcontract negotiation

Responding to change overfollowing a plan

Let’s Talk Agile.

Scrum

Sprints

Backlog

ProductOwner

Grooming

Stories

Meetings

Let’s Talk Agile.

Spring Backlog SprintProduct Backlog Deliverables

Let’s Talk Agile.

Kanban

Incremental

Cycle Time

Just in Time

WIP

Boards

Visibility

Let’s Talk Agile.

++SDL;

Reflecting on Agile:

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

++SDL;

Microsoft SDL framework

++SDL;

Agile Security (Bryan Sullivan, 2010 @ BH)

++SDL;

Agile Security (Bryan Sullivan, 2010 @ BH)

Sprint

• Essential

Performed every sprint

Bucket

• Importanton a regular basis but can be spread across multiple sprints

One time

• Foundational

once at the start of every new Agile project

++SDL;

Reflecting on Agile:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Meetings, meetings everywhere!

++SDL;

Sprint of 2 weeksOverlooking 4 teamsParticipating in every daily Daily is 15 minutes

10 days X 4 teams X 15 min. = 10 hours ~ 1 day= 10% of your sprint time

++SDL;

Security ChampionsTeam’s “security bouncer”

• Security friendly• Eyes and ears on meetings• Potential for security team

++SDL;

Examples for security tasks on each sprint:

++SDL;

Reflecting on Agile:

“Welcome changing requirements, even late in development.”

Threat modeling not only for new features, but also for CHANGED features

++SDL;

Threat Modeling:

• Attack / software / asset centric?• Assets• Actors• Entry points• Flow Not as lightweight as expected for sprint security task

++SDL;

Short, Easy, Threat Modeling..?

++SDL;

Coordinating with Product OwnerEmperor of the backlog

• Product’s roadmap• Features with high security

attention• Setting security sprints (bucket

security tasks)• Cut-off for most important threats

++SDL;

From Threats to Bug Bars

List of relevant threats Translating to impactCreating thresholds

Bucket: “Create Security Bug Bars”

The Team

Reflecting on Agile:

“The best architectures, requirements, and designsemerge from self-organizing teams.”

Teams contain different positions, responsibilities, practices and quite versatile

The Team

Security + Agile = Fail (Adrian Lane, 2010)

The Team

Team Leader Developer / Architect

QA

System Analyst The Security Guy

The Team

Must security training become complicated?

Start training by position, not by team

The TeamTraining Name Developer Architects Functional

AnalystSecurity Team

QA TeamLeaders

PM

Basic Security Training

Yes Yes Yes Yes Yes Yes (notest)

Optional

Security Analysis

Optional Optional Yes Yes Opt. Opt. Optional

Secure Design Optional Yes Optional Yes Opt. Opt. Optional

Secure Development

Yes Yes Optional Yes Opt. Yes (notest)

Optional

Security Testing

Optional Optional Optional Yes Yes Opt. Optional

Adv. Security Testing

Optional Optional Optional Yes Opt. Opt. Optional

Risk Management

Optional Optional Optional Yes Opt. Yes (no test)

Yes (no test)

Visibility

Reflecting on Agile:

“Build projects around motivated individuals.Give them the environment and support they need, and trust them to get the job done.”

How to surround with security?

Visibility

Board Shenanigans

Where are the security activities?

Visibility

Security as a shadowIt will follow you anyways

• Coupling lanes with security lanes• Design += Design Review• Development += CR / Static Analysis• QA += Penetration Testing / Fuzzing

• Add security cards (race conditions)

Visibility

Visibility

Security Flow

Reflecting on Agile:

“Business people and Developers must work together Daily throughout the project.”

Security Flow

Fixing Security Bugs:

Meetings with PM, Dev team, security, etc.

Security Flow

Agree on a bug fixing schemeFocus on work, not negotiation

• Time based (SLA) – Challenging!• Quota based (WIP)• Size based (Story Points)

Across all products (needs prioritization) Per product

Measuring Security

Reflecting on Agile:

“Working software is the primary measure of progress.”

Ok, but how do I measure security?

Measuring Security

Agile differs from Waterfall in:• Building a big picture from small iterations• Collecting evidence of simultaneous

activities• Vague control points

• Sprint?• Group of sprints?• Version release?

Measuring Security

Mastering Security in Agile (Ericsson, 2012)

Measuring Security

Fight Agile with Agile:

• Security cards: velocity, cycle time, etc.• Grooming evaluation:

• Card gets a ‘security level’ score• Score means level of security attention• Card is done collect evidence

• Automation, automation, automation

Questions?

(A reminder)

• Agile and security integration has hidden risks

• Taking measures before the risks turn to reality will prevent possible fails

• Use use Agile good sides to practice security, get rid of the bad ones

• Look for the

top related