Bootstrapping secure by design processes in a low-process, peer … · 2017-11-23 · Bootstrapping...
Transcript of Bootstrapping secure by design processes in a low-process, peer … · 2017-11-23 · Bootstrapping...
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