Practical Magic: Behavior- based Security Design for IoT Kelly - PowerPoint PPT Presentation

Practical Magic: Behavior- based Security Design for IoT Kelly Shortridge (@swagitda_) Troopers 2018

Hi, I’m Kelly

“I usually solve problems by letting them devour me.” ― Franz K afka 3

100 90 80 70 60 50 40 30 20 10 0 January 1, 2007 January 1, 2009 January 1, 2011 January 1, 2013 January 1, 2015 January 1, 2017 IoT IoT Security Source: Google Trends 4

We’re engendering a Kafkaesque paradigm for IoT security 5

Reaper Botnet RSAC 2017 100 90 80 Dyn DDoS / 70 Mirai Botnet 60 50 40 30 20 10 0 January 1, 2007 January 1, 2009 January 1, 2011 January 1, 2013 January 1, 2015 January 1, 2017 Source: Google Trends 6

IoT botnets are the first, and ravenous, boss of the IoT security battle 7

Mirai: 60 default passwords led to 100k node botnet attack against Dyn 8

But we’re promoting complexity & a seemingly endless set of hurdles 9

Lackluster IoT security is not a secret – our ideas are clearly not working 10

By understanding behavior, we can guide choice & support secure habits 11

1. Existing Suggestions 2. Incentive Problems 3. Behavior-Based Design 4. IoT Security Ideas 12

Existing Suggestions

FTC recommends building-in security from the beginning (simple as that!) 14

FDA: Pre- & Post-Market Guidelines (H/T @marasawr) 15

Pre-market: a lot of documentation & threat modelling 16

Post-market: monitoring & a mitigation deployment strategy 17

OWASP: IoT Testing Guide, IoT Attack Surface Areas, Principles of IoT Sec… 18

Designed for the penetration tester user persona – not developers 19

Cisco’s guidelines: “Secure Analytics,” Network Enforced Policy, Auth^2 20

Compensating Controls: post-market remedies by third parties 21

Burden is primarily on the end user 22

Actionable, real-time behavioral analytics for visibility & intelligence… 23

Maybe feasible for enterprises, but what are consumers to do? 24

Incentive Problems

Principal-agent problem: someone else makes the decisions, but you bear the impact 26

The Agent has their own self-interest. It’s likely not the same as yours. 27

Moral Hazard: people take more risks because someone else bears the cost 28

Next level: Equifax’s customers aren’t the end users whose data is stored 29

Prospect Theory: people care about relative vs. objective outcomes 30

Maintain a reference point against which outcomes are measured 31

Overweight small probabilities & underweight large probabilities 32

Overhyping low-probability vuln exploitation vs. default passwords 33

Loss aversion: people prefer to avoid losses vs. acquire the same gain 34

Framing security as a time & cost sink facilitates natural resistance 35

Hyperbolic discounting: future rewards are discounted vs. present 36

Many security initiatives are “investments” with long -term benefits 37

Dual System Theory: lizard brain (system 1) vs. philosopher brain (sys 2) 38

Most policies work on System 2 – we need to work with System 1 instead 39

Overchoice: too many options causes analysis paralysis 40

Which of the 100 items do devs tackle 1 st in a 10-page IoT attack surface doc? 41

We have to work with how people think, not against it 42

Behavior-based Design

What is choice architecture? 44

Design presentation of choices to promote improved decision-making 45

Example: MINDSPACE framework for behavioral design 46

Messenger: people dismiss info from sources they don’t like / respect 47

Incentives: losses can be more motivating than rewards 48

Norms: People follow social standards, (even when counterproductive) 49

Defaults: People prefer things to remain the same (inertia) 50

Salience: Novel & relevant draws attention & influences choices 51

Priming: Senses subconsciously influence us 52

Affect: Emotional reactions are our brains’ first responders 53

Commitments: Judgements made in advance to create “automatic” actions 54

Ego: People like to feel better about themselves & preserve self-image 55

Reinforcement mechanisms: consequences to guide behavior 56

Pay-for-performance lacks empirical evidence for fixing moral hazard 57

Set clear, achievable goals – “fix all the bugs” is neither 58

Goal setting must be matched with feedback, ideally immediate 59

Framing effects: reduce the gap between concern & willingness to act 60

Focus on leveraging system 1 to your advantage by altering habits 61

How do you create a habit loop? 62

Step 1: Routine 63

Make it stable, frictionless, & fit into existing context 64

Minimize perceived effort & number of decisions the user has to make 65

Step 2: Triggers & Rewards 66

Contextual cues: “If X, do Y” 67

Magical brew of rewards: mix of short- term & accumulated long-term ones 68

Step 3: Ingrain 69

Foster ample opportunities for practice & interaction 70

Cultivate a sense of meaning behind the habit – a deeper purpose 71

People don’t like feeling like habit machines; play into self-identity 72

Ideas for IoT Sec

Set concrete goals: “build - in security” is too nebulous 74

“Ensure each feature release uses a 10- point checklist” is a clear ask 75

Value should consider maximum security benefit at minimum cost 76

How to turn security into a habit? 77

Teams should have a regular, brief time & space to review security goals 78

Context cues: “if login portal, require change of default creds during setup” 79

Specify attainable steps with minimal complexity, like a checklist 80

Security suitably serves as a deeper purpose – frame it as a noble cause 81

How can we leverage MINDSPACE for IoT security? 82

Find the right messenger: preachy infosec people probably aren’t it 83

“Gift” budget that is eroded if security goals aren’t met (loss aversion) 84

Treat security habits as norms: “90% of our developers fix bugs within 3 days” 85

Show long-term expenses of options to highlight ROI of proactive security 86

Transparency around quality & cost: easiest measures with highest impact 87

Control instincts to security issues – slow down via threat modelling 88

Team bonus if you complete the checklist & fix bugs within 30 days – if not, it goes to charity 89

Black Girls Code, Calyx Institute, IFF Diversity & Inclusion Fund, Mozilla Foundation, Signal Foundation 90

Public lists of IoT vendors allowing default cred changes (like the Two Factor Auth List) 91

One-page checklist to ensure & document IoT security basics 92

Streamlined number of steps per lifecycle stage – design, build, test 93

1. Design UX workflow to change default passwords (everywhere) 94

2. Spoof headers to look like most common web servers 95

3. Encrypt data in transit with SSL or TLS 96

4. Don’t call bash scripts from the web interface 97

5. Don’t use custom API protocols – just use REST or SOAP 98

Design Build Test Does the device use: Share essential information • • • Tester to confirm: concerning security steps with • A login portal? • Completion of account the team Yes, and we allow controls (default • the change of Confirm each team member credential alerts, lockouts, • default creds understands the security 2FA) requirements • No • List of data used by the • User Data • Have any new features been device, and labelling of added since design that user data Yes, & we encrypt • require review? (ie interfacing data w/ SSL or TLS Whether there are any • w/ the internet, collecting user No vulnerabilities to be • data) addressed • Web Interface • Anticipated Security Events • Yes, and we do not • For builders: What are the critical or • call bash scripts or What are the key • non-routine security use custom API concerns around controls required? protocols management going How long will • • No forward and any future implementation of security concerns? If internet-connected, spoof controls take? headers to appear “normal” Instructions for • What are the anticipated • immediate post-testing Cross-checking by teams of impacts of the controls? security management are critical measures to be taken drawn up together 99

Formalized & usable checklist to be released soon… 100