Bootstrapping secure by design processes in a low-process, peer-to-peer engineering

organizationAndrey Labunets

Engineering security, making trade-offs at FacebookDefensive Track, Zeronights 2017

A moderately inspiring keynote

Why I am hereZeronights CFP: new attacks, techniques, bypasses, exploitation

Is defense still uninteresting?

Key points of this talk

• Offense is saturated with ideas, but not defense

• Defense work is unique, but its role is underestimated

ContentsIntro. Basic blocks: secure by design, constraints, agile

Theory. Secure by design, constraints, and agile are hard to combine

Practice. Bootstrapping secure by design processes in a low-process mode

Exploratory. Product security at scale

Intro. Basic blocks: secure by design, constraints, agile

Secure by design

•System should be built with security in mind from the ground up

•Security engineers are involved on early phases:

•Requirements

•Architecture / design

•Most annoying part of any secure development methodology

•Once chosen, architecture/design are hard to roll back

Constraints & trade-offs

1 security engineer per 20 products

CPU usage not more than N%

Uptime 99,999%

Encryption at the cost of performance

Fail-closed ACL at the cost of availability

End-to-end encryption at the cost of fraud detection

CAP theorem

…etc

Constraints on1 parameter

Constraints on2 parameters

Constraints on3 parameters

Technical

Organizational

• Real constraints are defined in a multidimensional parameter space (performance, reliability, usability, delivery time, etc)

• Dependencies are complex and hardly expressed analytically

• Design is choice within the given constraints

Naive example: a trade-off between A and B

System’s constraints are often invisible to anyone except its architects

Agile

•Early delivery

•Simultaneous phases

•Continuous improvement

•Adaptive planning and A/B tests

Theory. Secure by design, constraints, and agile are hard to combine

Secure by design and organizational constraints

• Mandatory audit for all changes is at the cost of blocking requests

• The more audit layers - the more operational risks

• Strict policy has a limited resource of no

• Test / static check infra should not become stale, or it will be bypassed

• Organizational complexity, same as systems complexity, accumulates rapidly

Secure by design and technical constraints

• Q: put an access control here? hmac is just a line of code

• A: Clients are 3rd-party consumer hardware, new segment url format crash some % of them

• Reducing technical risks at the cost of reliability and more business risks?

• At our scale, we can’t afford saying “it’s their problem”, we need an optimal solution for the platform

Secure by design and agile: asymmetry of change and effect

Sets of properties Implementations

• Every small code change can redefine the properties we need and the properties are held

• Every new property can be a huge change in implementation

• Phases collapse in agile, borders between one-line change and a new product dissolve

• Every small code change can redefine the properties we need and the properties are held

• Every new property can be a huge change in implementation

• Protocols, state machines, network, architecture, logic are the most hardcore in agile

• Need to workaround the asymmetry

• Avoid security/engineers slowing down each other

Secure by design and agile: asymmetry of change and effect

Prioritization is an improvisation

• Requirements phase: “just set a quality gate and never relax it”

• Ok, Let’s agree on launch-blocking bugs

• Q1: What is launch?

• Q2: What’s blocking?

• Ex: CEO uses product A to announce launch of the product A and other products

• Very much of a launch, not much of a blocking

Product launch, awareness, and risks

Launch

CEO posts about the product

Product is announcedat a conference First security reports

Use

rs

Time8 hours

difference6 daysdifferenceN months

difference

Secure by design

Define secure? Define design?• Constraints, trade-offs

• Assumptions change in the process

• 3rd-party components designed/evolving separately

• Prototype-based, experiment-driven design

• Repurposed systems

Secure by design, agile, and constraints are hard to combine

Practice. Bootstrapping secure by design processes in a low-process mode

Soft skills is the new hacking

• Applying individual tools and practices depends on a situation

• Making them actually work in the given org is crucial

• Offense is a technical problem, defense is a political human logistical problem

• Implementation of a complex operation is a thing

• Social engineering does not apply either

Product security in Agile

Empathy is an nmap for humans

• Anti-pattern: “We, infosec, are smarter, we told them to secure it, but they don’t listen”

• Not our level. We can’t afford thinking this↑, because it helps no one

• What works:

• “Fingerprinting” what engineers think

• Finding a root cause

• Identifying constraints

• Fixing a problem systemically, within the constraints

Exploit primitives for organizations

Consulting: a limited write-what-where primitive

Security Engineer

Product Team

Exploit primitives for organizations

Product Team

Security Engineer

Influence: a full write-what-where primitive

Exploratory. Product security at scale

Program analysis

Given a memory read pattern, can you say what code does?Offs

et (

0x-…

)

Time

Program analysis

• Sometimes yes: these sequential reads suggest it’s a parser

• We don’t always need program analysis as a bug-finding or verification tool

• We can use it for recognizing system components

Offs

et (

0x-…

)

Time

Recognizing system components

• We can recognize components statically too

• With a 200-LoC script we find parsers in our ~30 mLoC C++ code

• Diverse codebase (different teams, frameworks, freshness, OSI layer)

• High accuracy

• Tolerable noise

• Impact:

• Quicker, more effective code audits

• Detecting attack surface changes in fast-moving codebase

• Other components we need to recognize: access controls, storage, cryptography, …

• We are distracted too much by individual vulnerabilities or attacks

• Classifying systems/components, studying their lifecycle, inferring what defense works for each type is much more useful

What product lifecycle

What product lifecycle

What product lifecycle

• Life of a system is an arms-race with multiple parties: attackers, researchers, competitors, regulators

• Features and complexity are a product of an ecosystem

• Defense priority is adaptation to changing environment and survival

• We have to build security within these limitations

• Offense is saturated with ideas, unlike defense

• Defense work is unique, but its role is underestimated

Good luck finding your ways

Q&A