Application SecurityNetlight

EDGE

Who am I?• Dimitrios Stergiou (@dstergiou)• Information Security Manager @ NetEnt• 7 years InfoSec experience in gaming

companies• 15 years InfoSec experience (engineer,

consultant,manager)

• Mini bio:• Greek (and Swede)• Loves: InfoSec, Social Engineering,

Economics, Video games• Hates: Vegetables, Rain, Pronouncing

“j” as “y”

DisclaimerI don’t have the ultimate truth

But I am also NOT trying to sell you anything

Listen, question and take everything with a grain of salt

Application security placement• Server• Custom-developed

application• Server• Protocols like HTTP, SSH,

SMTP• Router• TCP,

UDP• Switch• IP, ARP,

ICMP• Ethernet• Network cards, fibers,

leased lines

In-house code

Application Transport Network Physical

What doesn’twork?Let’s talk about 4 approaches to Application Security that don’t (generally) produce results

4 FAIL approaches to AppSec

Bolt on Security

•Functional first, Security afterwards•Weakness: Design decisions, long cycle to fixWaterfall Security•Prepare every security solution in advance•Weakness: Not Agile friendly (who does waterfall these days?)

“Random” Security•Implement every security countermeasure known to man•Weakness: Expensive, bloats the product / service, time-consuming

All or Nothing Security•Reactively implement all proposed security controls (usually after an audit)•Weakness: Too big of a chunk to bite, maybe overdoing it

So, what works?

Can you recommend a process?

OpenSAMMGovernance

Strategy & Metrics

Policy & Compliance

Education & Guidance

Construction

Security Requirements

Threat Assessment

Secure Architecture

Verification

Design Review

Security Testing

Code Review

Deployment

Environment Hardening

Vulnerability Management

Operational Enablement

BSIMMGovernance

Strategy & Metrics

Policy & Compliance

Training

Construction

Standards & Requirements

Attack Models

Security Features

& Design

Verification

Architecture Analysis

Security Testing

Code Review

Deployment

Software Environment

Configuration & Vulnerability Management

Penetration testing

Conclusion• We still don’t have an “absolute truth” – there is no standard for AppSec• But these 2 models

lookEXTREMELY similar

• So maybe we have some kind of consensus on what needs to be done

What are we trying to achieve?• Cover the basis

• Audit requirements• Regulatory

requirements

• Manage risk• Mitigate, avoid

OWASP, They grouped everything!

Some basics!

Error handling• Generic

error messages

• Handle all exceptions

• Log, log, log• But don’t

log everything

• Safeguard logs

Data protection• HTTP is

dead, so is SSL

• Use TLS everywhere

• Manage your crypto keys

• Avoid storingsensitive

data

Authentication• No

hardcoded credentials

• Proper password reset system

• Strong password policy

• Account lockout• Watch what

you disclose in error messages

Input & Output• Validate

everything

• Whitelists over blacklists

• Use token for CSRF protection

• User parameterized SQL queries

• Use Content- Security header

Session management• Random

session IDs• Force idle

session timeouts

• Invalidate sessions after logout

• Use “secure” and “httpOnly” for Cookies

Access control• Check

every request

• Least privilege• Avoid direct

object references

• Validate forwards and redirects

That is TOO much!

• How are we going to do all these things?

• “Do we need a security project?”

Agile &AppSec• Bring AppSec activities

into your Agile framework

• Iteration and continuity is key

• Breed new (improved) habits!

Exploration

Backlog

ArchitectureSpikes

User Stories

Iteration 0

Team setup

Process setup

Infrastructure setup

Iteration N

Backlog GroomingIncremental Delivery

User Stories

Release Preparation

Acceptance Test

Documentation

Release

PublishSecurity

ObjectivesMinimSeucmuritVyiable

RePqruoirdemucentts

Security SpikesVision / Scope

Abuse Stories

ThreatAbuseModelStoriesDesignCodeInspectInspectSecuritySecuritySRpiektersospecGtoivaels

Security Testing

Packaging /ReleaseSecurity Testing

Security Documentation

SecurityRetrospecti

ve

Typical Agile Organization

Latestnightmare• Not a bad idea, but…

• … there is a difference between DevOps and the “Wild, wild west”

SimplifiedDevOps• End-to-end product

team

• Responsible for the full lifecycle of the product

• BUT…

Etsy, the poster boy (or girl)• “Invented

DevOps”

• Made it a trend

• But…

Fine print:Etsy built a new, segmented PCI-DSS compliant environment for their payment systems - "we built a whole separate Etsy, essentially";

In the payments environment they "still have to follow the rules: a developer still doesn't have access to a production database", but they'll have dbas working alongside them who they can ask for help, and graphs showing metrics from the database

R E A L I T Y

Should we DevOps?

Benefits• Time to market• Ownership & Culture• Security actually

improves• Knowledge spread• Improved product

Caveats• Without discipline, chaos• Without automation, chaos• Jack of all trades, master of

none• Segregation of duties out the

door• Regulators not ready yet

What about security, SevDevOps?

SecOps Provide “secure”

baselines for the DevOps teams

Pass test results and risk assessments to DevOps ASAP

Monitor all things – threat landscape changes by the minute

Deliver security as code