0%

Book Description

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.

Table of Contents

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