Secure By Design

by Daniel Deogun, Dan Bergh Johnsson, Daniel Sawano

Overview

Summary

Secure by Design teaches developers how to use design to drive security in software development. This book is full of patterns, best practices, and mindsets that you can directly apply to your real world development. You'll also learn to spot weaknesses in legacy code and how to address them.

Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications.

About the technology

Security should be the natural outcome of your development process. As applications increase in complexity, it becomes more important to bake security-mindedness into every step. The secure-by-design approach teaches best practices to implement essential software features using design as the primary driver for security.

About the book

Secure by Design teaches you principles and best practices for writing highly secure software. At the code level, you’ll discover security-promoting constructs like safe error handling, secure validation, and domain primitives. You’ll also master security-centric techniques you can apply throughout your build-test-deploy pipeline, including the unique concerns of modern microservices and cloud-native designs.

What's inside

Secure-by-design concepts
Spotting hidden security problems
Secure code constructs
Assessing security by identifying common design flaws
Securing legacy and microservices architectures

About the reader

Readers should have some experience in designing applications in Java, C#, .NET, or a similar language.

About the author

Dan Bergh Johnsson, Daniel Deogun, and Daniel Sawano are acclaimed speakers who often present at international conferences on topics of high-quality development, as well as security and design.

Product Details

ISBN-13:	9781617294358
Publisher:	Manning
Publication date:	09/06/2019
Edition description:	1st Edition
Pages:	410
Sales rank:	1,057,204
Product dimensions:	7.30(w) x 9.10(h) x 0.80(d)

About the Author

Daniel Deogun has a masters degree in computer science and is a senior consultant and VP at Omegapoint in Sweden. He specializes in the crossing between application development and security. His experience ranges from life supporting systems to web applications to high-performance software in various fields. Combining this with his passion for high quality design have made him a frequent speaker at renowned conferences all over the world.

Dan Bergh Johnsson is a senior consultant and VP at Omegapoint in Sweden. Dan is an Agile aficionado, Domain Driven Design enthusiast, and code quality craftsman, with a long time interest in security. While working in the crossroad of system development and security, he has helped numerous clients in different domains towards higher security of their custom-built systems. Dan shares his passion as a regular speaker at renowned international conferences as well as on his blog Dear Junior.

Daniel Sawano is a software developer, architect, and frequent speaker at international conferences. He has extensive experience from working with high-performance systems in industries such as stock trading, gaming, telco, and media. Daniel holds a master of science degree and is passionate about software design, performance, and security. He is an advocate of combining good software design principles with security thinking to create systems that are both secure and agile.

Table of Contents

Foreword xv

Preface xix

Acknowledgments xxi

About this book xxiii

About the authors xxvii

About the cover illustration xxix

Part 1 Introduction 1

1 Why design matters for security 3

1.1 Security is a concern, not a feature 5

The robbery of Öst-Gotha Bank, 1854 5

Security features and concerns 6

Categorizing security concerns: CIA-T 8

1.2 Defining design 9

1.3 The traditional approach to software security and its shortcomings 11

Explicitly thinking about security 14

Everyone is a security expert 14

Knowing all and the unknowable 14

1.4 Driving security through design 14

Making the user secure by design 15

The advantages of the design approach 18

Staying eclectic 21

1.5 Dealing with strings, XML, and a billion laughs 21

Extensible Markup Language (XML) 22

Internal XML entities in a nutshell 22

The Billion Laughs attack 23

Configuring the XML parser 23

Applying a design mindset 25

Applying operational constraints 28

Achieving security in depth 28

2 Intermission: The anti-Hamlet 31

2.1 An online bookstore with business integrity issues 33

The inner workings of the accounts receivable ledger 35

How the inventory system tracks books in the store 36

Shipping anti-books 37

Systems living the same lie 38

A do-it-yourself discount voucher 38

2.2 Shallow modeling 39

How shallow models emerge 41

The dangers of implicit concepts 42

2.3 Deep modeling 43

How deep models emerge 43

Make the implicit explicit 45

Part 2 Fundamentals 47

3 Core concepts of Domain-Driven Design 49

3.1 Models as tools for deeper insight 51

Models are simplifications 53

Models are strict 56

Models capture deep understanding 59

Making a model means choosing one 61

The model forms the ubiquitous language 63

3.2 Building blocks for your model 65

Entities 66

Value objects 70

Aggregates 73

3.3 Bounded contexts 77

Semantics of the ubiquitous language 77

The relationship between language, model, and bounded context 78

Identifying the bounded context 78

3.4 Interactions between contexts 81

Sharing a model in two contexts 82

Drawing a context map 83

4 Code constructs promoting security 87

4.1 Immutability 88

An ordinary webshop 88

Failing fast using contracts 95

Checking preconditions for method arguments 97

Upholding invariants in constructors 99

Failing for bad state 101

4.3 Validation 102

Checking the origin of data 103

Checking the size of data 105

Checking lexical content of data 107

Checking the data syntax 109

Checking the data semantics 110

5 Domain primitives 113

5.1 Domain primitives and invariants 114

Domain primitives as the smallest building blocks 114

Context boundaries define meaning 116

Building your domain primitive library 118

Hardening APIs with your domain primitive library 119

Avoid exposing your domain publicly 120

5.2 Read-once objects 121

Detecting unintentional use 123

Avoiding leaks caused by evolving code 125

5.3 Standing on the shoulders of domain primitives 127

The risk with overcluttered entity methods 127

Decluttering entities 129

When to use domain primitives in entities 132

5.4 Taint analysis 133

6 Ensuring integrity of state 137

6.1 Managing state using entities 138

6.2 Consistent on creation 140

The perils of no-arg constructors 140

ORM frameworks and no-arg constructors 142

All mandatory fields as constructor arguments 143

Construction with a fluent interface 147

Catching advanced constraints in code 149

The builder pattern for upholding advanced constraints 151

ORM frameworks and advanced constraints 155

Which construction to use when 155

6.3 Integrity of entities 156

Getter and setter methods 156

Avoid sharing mutable objects 158

Securing the integrity of collections 160

7 Reducing complexity of state 164

7.1 Partially immutable entities 166

7.2 Entity state objects 168

Upholding entity state rules 168

Implementing entity state as a separate object 172

7.3 Entity snapshots 174

Entities represented with immutable objects 175

Changing the state of the underlying entity 177

When to use snapshots 180

7.4 Entity relay 181

Splitting the state graph into phases 183

When to form an entity relay 186

8 Leveraging your delivery pipeline for security 189

8.1 Using a delivery pipeline 190

8.2 Securing your design using unit tests 191

Understanding the domain rules 192

Testing normal behavior 193

Testing boundary behavior 194

Testing with invalid input 197

Testing the extreme 200

8.3 Verifying feature toggles 201

The perils of slippery toggles 201

Feature toggling as a development tool 202

Taming the toggles 205

Dealing with combinatory complexity 209

Toggles are subject to auditing 209

8.4 Automated security tests 210

Security tests are only tests 210

Working with security tests 211

Leveraging infrastructure as code 212

Putting it into practice 212

8.5 Testing for availability 213

Estimating the headroom 213

Exploiting domain rules 215

8.6 Validating configuration 216

Causes for configuration-related security flaws 216

Automated tests as your safety net 218

Knowing your defaults and verifying them 219

9 Handling failures securely 223

9.1 Using exceptions to deal with failure 224

Throwing exceptions 225

Handling exceptions 227

Dealing with exception payload 231

9.2 Handling failures without exceptions 232

Failures aren't exceptional 232

Designing for failures 234

9.3 Designing for availability 237

Resilience 237

Responsiveness 238

Circuit breakers and timeouts 238

Bulkheads 241

9.4 Handling bad data 244

Don't repair data before validation 245

Never echo input verbatim 247

10 Benefits of cloud thinking 251

10.1 The twelve-factor app and cloud-native concepts 252

10.2 Storing configuration in the environment 253

Don't put environment configuration in code 254

Never store secrets in resource files 255

Placing configuration in the environment 256

10.3 Separate processes 258

Deploying and running are separate things 258

Processing instances don't hold state 259

Security benefits 261

10.4 Avoid logging to file 261

Confidentiality 262

Integrity 262

Availability 263

Logging as a service 263

10.5 Admin processes 266

The security risk of overlooked admin tasks 267

Admin tasks as first-class citizens 267

10.6 Service discovery and load balancing 269

Centralized load balancing 269

Client-side load balancing 270

Embracing change 271

10.7 The three R's of enterprise security 271

Increase change to reduce risk 272

Rotate 273

Repave 274

Repair 276

11 Intermission: An insurance policy for free 278

11.1 Over-the-counter insurance policies 279

11.2 Separating services 280

11.3 A new payment type 281

11.4 A crashed car, a late payment, and a court case 285

11.5 Understanding what went wrong 287

11.6 Seeing the entire picture 287

11.7 A note on microservices architecture 292

Part 3 Applying the Fundamentals 293

12 Guidance in legacy code 295

12.1 Determining where to apply domain primitives in legacy code 296

12.2 Ambiguous parameter lists 297

The direct approach 299

The discovery approach 300

The new API approach 302

12.3 Logging unchecked strings 303

Identifying logging of unchecked strings 303

Identifying implicit data leakage 304

12.4 Defensive code constructs 305

Code that doesn't trust itself 306

Contracts and domain primitives to the rescue 308

Overlenient use of Optional 309

12.5 DRY misapplied-not focusing on ideas, but on text 310

A false positive that shouldn't be DRY'd away 311

The problem of collecting repeated pieces of code 311

The good DRY 312

A false negative 312

12.6 Insufficient validation in domain types 313

12.7 Only testing the good enough 315

12.8 Partial domain primitives 316

Implicit, contextual currency 317

A U.S. dollar is not a Slovenian tolar 318

Encompassing a conceptual whole 319

13 Guidance on microservices 322

13.1 What's a microservice? 323

Independent runtimes 324

Independent updates 324

Designed for down 324

13.2 Each service is a bounded context 325

The importance of designing your API 326

Splitting monoliths 328

Semantics and evolving services 329

13.3 Sensitive data across services 329

CIA-T in a microservice architecture 330

Thinking "sensitive" 331

13.4 Logging in microservices 332

Integrity of aggregated log data 333

Traceability in log data 334

Confidentiality through a domain-oriented logger API 337

14 A final word: Don't forget about security! 343

14.1 Conduct code security reviews 344

What to include in a code security review 345

Whom to include in a code security review 346

14.2 Keep track of your stack 346

Aggregating information 346

Prioritizing work 347

14.3 Run security penetration tests 347

Challenging your design 348

Learning from your mistakes 349

How often should you run a pen test? 349

Using bug bounty programs as continuous pen testing 350

14.4 Study the field of security 351

Everyone needs a basic understanding about security 351

Making security a source of inspiration 352

14.5 Develop a security incident mechanism 353

Incident handling 354

Problem resolution 354

Resilience, Wolff's law, and antifragility 356

Index 361