Secure By Design

Description

As a developer, you need to build software in a secure way. But you can't spend all your time focusing on security. The answer is to use good design principles, tools, and mindsets that make security an implicit result - it's secure by design. 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. Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications. Secure by Design brief contents contents foreword preface acknowledgments about this book about the authors about the cover illustration Part 1: Introduction 1 Why design matters 1.1 Security is a concern, not a feature 1.1.1 The robbery of Öst-Götha Bank, 1854 1.1.2 Security features and concerns 1.1.3 Categorizing security concerns: CIA-T 1.2 Defining design 1.3 The traditional approach to software security and its shortcomings 1.3.1 Explicitly thinking about security 1.3.2 Everyone is a security expert 1.3.3 Knowing all and the unknowable 1.4 Driving security through design 1.4.1 Making the user secure by design 1.4.2 The advantages of the design approach 1.4.3 Staying eclectic 1.5 Dealing with strings, XML, and a billion laughs 1.5.1 Extensible Markup Language (XML) 1.5.2 Internal XML entities in a nutshell 1.5.3 The Billion Laughs attack 1.5.4 Configuring the XML parser 1.5.5 Applying a design mindset 1.5.6 Applying operational constraints 1.5.7 Achieving security in depth 2 Intermission: 2.1 An online book store with business integrity issues 2.1.1 The inner workings of the accounts receivable ledger 2.1.2 How the inventory system tracks books in the store 2.1.3 Shipping anti-books 2.1.4 Systems living the same lie 2.1.5 A do-it-yourself discount voucher 2.2 Shallow modeling 2.2.1 How shallow models emerge 2.2.2 The dangers of implicit concepts 2.3 Deep modeling 2.3.1 How deep models emerge 2.3.2 Make the implicit explicit Part 2: Fundamentals 3 Core concepts of 3.1 Models as tools for deeper insight 3.1.1 Models are simplifications 3.1.2 Models are strict 3.1.3 Models capture deep understanding 3.1.4 Making a model means choosing one 3.1.5 The model forms the ubiquitous language 3.2 Building blocks for your model 3.2.1 Entities 3.2.2 Value objects 3.2.3 Aggregates 3.3 Bounded contexts 3.3.1 Semantics of the ubiquitous language 3.3.2 The relationship between language, model, and bounded context 3.3.3 Identifying the bounded context 3.4 Interactions between contexts 3.4.1 Sharing a model in two contexts 3.4.2 Drawing a context map 4 Code constructs 4.1 Immutability 4.1.1 An ordinary webshop 4.2 Failing fast using contracts 4.2.1 Checking preconditions for method arguments 4.2.2 Upholding invariants in constructors 4.2.3 Failing for bad state 4.3 Validation 4.3.1 Checking the origin of data 4.3.2 Checking the size of data 4.3.3 Checking lexical content of data 4.3.4 Checking the data syntax 4.3.5 Checking the data semantics 5 Domain primitives 5.1 Domain primitives and invariants 5.1.1 Domain primitives as the smallest building blocks 5.1.2 Context boundaries define meaning 5.1.3 Building your domain primitive library 5.1.4 Hardening APIs with your domain primitive library 5.1.5 Avoid exposing your domain publicly 5.2 Read-once objects 5.2.1 Detecting unintentional use 5.2.2 Avoiding leaks caused by evolving code 5.3 Standing on the shoulders of domain primitives 5.3.1 The risk with overcluttered entity methods 5.3.2 Decluttering entities 5.3.3 When to use domain primitives in entities 5.4 Taint analysis 6 Ensuring integrity of state 6.1 Managing state using entities 6.2 Consistent on creation 6.2.1 The perils of no-arg constructors 6.2.2 ORM frameworks and no-arg constructors 6.2.3 All mandatory fields as constructor arguments 6.2.4 Construction with a fluent interface 6.2.5 Catching advanced constraints in code 6.2.6 The builder pattern for upholding advanced constraints 6.2.7 ORM frameworks and advanced constraints 6.2.8 Which construction to use when 6.3 Integrity of entities 6.3.1 Getter and setter methods 6.3.2 Avoid sharing mutable objects 6.3.3 Securing the integrity of collections 7 Reducing complexity 7.1 Partially immutable entities 7.2 Entity state objects 7.2.1 Upholding entity state rules 7.2.2 Implementing entity state as a separate object 7.3 Entity snapshots 7.3.1 Entities represented with immutable objects 7.3.2 Changing the state of the underlying entity 7.3.3 When to use snapshots 7.4 Entity relay 7.4.1 Splitting the state graph into phases 7.4.2 When to form an entity relay 8 Leveraging your delivery pipeline for security 8.1 Using a delivery pipeline 8.2 Securing your design using unit tests 8.2.1 Understanding the domain rules 8.2.2 Testing normal behavior 8.2.3 Testing boundary behavior 8.2.4 Testing with invalid input 8.2.5 Testing the extreme 8.3 Verifying feature toggles 8.3.1 The perils of slippery toggles 8.3.2 Feature toggling as a development tool 8.3.3 Taming the toggles 8.3.4 Dealing with combinatory complexity 8.3.5 Toggles are subject to auditing 8.4 Automated security tests 8.4.1 Security tests are only tests 8.4.2 Working with security tests 8.4.3 Leveraging infrastructure as code 8.4.4 Putting it into practice 8.5 Testing for availability 8.5.1 Estimating the headroom 8.5.2 Exploiting domain rules 8.6 Validating configuration 8.6.1 Causes for configuration-related security flaws 8.6.2 Automated tests as your safety net 8.6.3 Knowing your defaults and verifying them 9 Handling failures securely 9.1 Using exceptions to deal with failure 9.1.1 Throwing exceptions 9.1.2 Handling exceptions 9.1.3 Dealing with exception payload 9.2 Handling failures without exceptions 9.2.1 Failures aren’t exceptional 9.2.2 Designing for failures 9.3 Designing for availability 9.3.1 Resilience 9.3.2 Responsiveness 9.3.3 Circuit breakers and timeouts 9.3.4 Bulkheads 9.4 Handling bad data 9.4.1 Don’t repair data before validation 9.4.2 Never echo input verbatim 10 Benefits of cloud thinking 10.1 The twelve-factor app and cloud-native concepts 10.2 Storing configuration in the environment 10.2.1 Don’t put environment configuration in code 10.2.2 Never store secrets in resource files 10.2.3 Placing configuration in the environment 10.3 Separate processes 10.3.1 Deploying and running are separate things 10.3.2 Processing instances don’t hold state 10.3.3 Security benefits 10.4 Avoid logging to file 10.4.1 Confidentiality 10.4.2 Integrity 10.4.3 Availability 10.4.4 Logging as a service 10.5 Admin processes 10.5.1 The security risk of overlooked admin tasks 10.5.2 Admin tasks as first-class citizens 10.6 Service discovery and load balancing 10.6.1 Centralized load balancing 10.6.2 Client-side load balancing 10.6.3 Embracing change 10.7 The three R’s of enterprise security 10.7.1 Increase change to reduce risk 10.7.2 Rotate 10.7.3 Repave 10.7.4 Repair 11 Intermission: An insurance policy for free 11.1 Over-the-counter insurance policies 11.2 Separating services 11.3 A new payment type 11.4 A crashed car, a late payment, and a court case 11.5 Understanding what went wrong 11.6 Seeing the entire picture 11.7 A note on microservices architecture Part 3: Applying the fundamentals 12 Guidance in legacy code 12.1 Determining where to apply domain primitives in legacy code 12.2 Ambiguous parameter lists 12.2.1 The direct approach 12.2.2 The discovery approach 12.2.3 The new API approach 12.3 Logging unchecked strings 12.3.1 Identifying logging of unchecked strings 12.3.2 Identifying implicit data leakage 12.4 Defensive code constructs 12.4.1 Code that doesn’t trust itself 12.4.2 Contracts and domain primitives to the rescue 12.4.3 Overlenient use of Optional 12.5 DRY misapplied—not focusing on ideas, but on text 12.5.1 A false positive that shouldn’t be DRY’d away 12.5.2 The problem of collecting repeated pieces of code 12.5.3 The good DRY 12.5.4 A false negative 12.6 Insufficient validation in domain types 12.7 Only testing the good enough 12.8 Partial domain primitives 12.8.1 Implicit, contextual currency 12.8.2 A U.S. dollar is not a Slovenian tolar 12.8.3 Encompassing a conceptual whole 13 Guidance on microservices 13.1 What’s a microservice? 13.1.1 Independent runtimes 13.1.2 Independent updates 13.1.3 Designed for down 13.2 Each service is a bounded context 13.2.1 The importance of designing your API 13.2.2 Splitting monoliths 13.2.3 Semantics and evolving services 13.3 Sensitive data across services 13.3.1 CIA-T in a microservice architecture 13.3.2 Thinking “sensitive” 13.4 Logging in microservices 13.4.1 Integrity of aggregated log data 13.4.2 Traceability in log data 13.4.3 Confidentiality through a domain-oriented logger API 14 A final word: Don’t forget about security! 14.1 Conduct code security reviews 14.1.1 What to include in a code security review 14.1.2 Whom to include in a code security review 14.2 Keep track of your stack 14.2.1 Aggregating information 14.2.2 Prioritizing work 14.3 Run security penetration tests 14.3.1 Challenging your design 14.3.2 Learning from your mistakes 14.3.3 How often should you run a pen test? 14.3.4 Using bug bounty programs as continuous pen testing 14.4 Study the field of security 14.4.1 Everyone needs a basic understanding about security 14.4.2 Making security a source of inspiration 14.5 Develop a security incident mechanism 14.5.1 Incident handling 14.5.2 Problem resolution 14.5.3 Resilience, Wolff’s law, and antifragility index