book

Secure by Design

Name: Secure by Design
ISBN: 9781617294358

by Dan Bergh Johnsson, Daniel Deogun, Daniel Sawano

September 2019

Intermediate to advanced

400 pages

13h 13m

English

Manning Publications

Read now

Unlock full access

Secure by Design
brief contents
contents
front matter
forewordprefaceacknowledgmentsabout this bookWho should read this bookHow this book is organized: A roadmapAbout the codeliveBook discussion forumabout the authorsabout the cover illustration
Part 1 Introduction
1 Why design matters for security
1.1 Security is a concern, not a feature1.1.1 The robbery of Öst-Götha Bank, 18541.1.2 Security features and concerns1.1.3 Categorizing security concerns: CIA-T1.2 Defining design1.3 The traditional approach to software security and its shortcomings1.3.1 Explicitly thinking about security1.3.2 Everyone is a security expert1.3.3 Knowing all and the unknowable1.4 Driving security through design1.4.1 Making the user secure by design1.4.2 The advantages of the design approach1.4.3 Staying eclectic1.5 Dealing with strings, XML, and a billion laughs1.5.1 Extensible Markup Language (XML)1.5.2 Internal XML entities in a nutshell1.5.3 The Billion Laughs attack1.5.4 Configuring the XML parser1.5.5 Applying a design mindset1.5.6 Applying operational constraints1.5.7 Achieving security in depthSummary
2 Intermission: The anti-Hamlet
2.1 An online bookstore with business integrity issues2.1.1 The inner workings of the accounts receivable ledger2.1.2 How the inventory system tracks books in the store2.1.3 Shipping anti-books2.1.4 Systems living the same lie2.1.5 A do-it-yourself discount voucher2.2 Shallow modeling2.2.1 How shallow models emerge2.2.2 The dangers of implicit concepts2.3 Deep modeling2.3.1 How deep models emerge2.3.2 Make the implicit explicitSummary
Part 2 Fundamentals
3 Core concepts of Domain-Driven Design
3.1 Models as tools for deeper insight3.1.1 Models are simplifications3.1.2 Models are strict3.1.3 Models capture deep understanding3.1.4 Making a model means choosing one3.1.5 The model forms the ubiquitous language3.2 Building blocks for your model3.2.1 Entities3.2.2 Value objects3.2.3 Aggregates3.3 Bounded contexts3.3.1 Semantics of the ubiquitous language3.3.2 The relationship between language, model, and bounded context3.3.3 Identifying the bounded context3.4 Interactions between contexts3.4.1 Sharing a model in two contexts3.4.2 Drawing a context mapSummary
4 Code constructs promoting security
4.1 Immutability4.1.1 An ordinary webshop4.2 Failing fast using contracts4.2.1 Checking preconditions for method arguments4.2.2 Upholding invariants in constructors4.2.3 Failing for bad state4.3 Validation4.3.1 Checking the origin of data4.3.2 Checking the size of data4.3.3 Checking lexical content of data4.3.4 Checking the data syntax4.3.5 Checking the data semanticsSummary

5 Domain primitives
5.1 Domain primitives and invariants5.1.1 Domain primitives as the smallest building blocks5.1.2 Context boundaries define meaning5.1.3 Building your domain primitive library5.1.4 Hardening APIs with your domain primitive library5.1.5 Avoid exposing your domain publicly5.2 Read-once objects5.2.1 Detecting unintentional use5.2.2 Avoiding leaks caused by evolving code5.3 Standing on the shoulders of domain primitives5.3.1 The risk with overcluttered entity methods5.3.2 Decluttering entities5.3.3 When to use domain primitives in entities5.4 Taint analysisSummary
6 Ensuring integrity of state
6.1 Managing state using entities6.2 Consistent on creation6.2.1 The perils of no-arg constructors6.2.2 ORM frameworks and no-arg constructors6.2.3 All mandatory fields as constructor arguments6.2.4 Construction with a fluent interface6.2.5 Catching advanced constraints in code6.2.6 The builder pattern for upholding advanced constraints6.2.7 ORM frameworks and advanced constraints6.2.8 Which construction to use when6.3 Integrity of entities6.3.1 Getter and setter methods6.3.2 Avoid sharing mutable objects6.3.3 Securing the integrity of collectionsSummary
7 Reducing complexity of state
7.1 Partially immutable entities7.2 Entity state objects7.2.1 Upholding entity state rules7.2.2 Implementing entity state as a separate object7.3 Entity snapshots7.3.1 Entities represented with immutable objects7.3.2 Changing the state of the underlying entity7.3.3 When to use snapshots7.4 Entity relay7.4.1 Splitting the state graph into phases7.4.2 When to form an entity relaySummary
8 Leveraging your delivery pipeline for security
8.1 Using a delivery pipeline8.2 Securing your design using unit tests8.2.1 Understanding the domain rules8.2.2 Testing normal behavior8.2.3 Testing boundary behavior8.2.4 Testing with invalid inputTesting with input that causes eventual harm8.2.5 Testing the extreme8.3 Verifying feature toggles8.3.1 The perils of slippery toggles8.3.2 Feature toggling as a development tool8.3.3 Taming the toggles8.3.4 Dealing with combinatory complexity8.3.5 Toggles are subject to auditing8.4 Automated security tests8.4.1 Security tests are only tests8.4.2 Working with security tests8.4.3 Leveraging infrastructure as code8.4.4 Putting it into practice8.5 Testing for availability8.5.1 Estimating the headroom8.5.2 Exploiting domain rules8.6 Validating configuration8.6.1 Causes for configuration-related security flaws8.6.2 Automated tests as your safety net8.6.3 Knowing your defaults and verifying themSummary
9 Handling failures securely
9.1 Using exceptions to deal with failure9.1.1 Throwing exceptions9.1.2 Handling exceptions9.1.3 Dealing with exception payload9.2 Handling failures without exceptions9.2.1 Failures aren’t exceptional9.2.2 Designing for failures9.3 Designing for availability9.3.1 Resilience9.3.2 Responsiveness9.3.3 Circuit breakers and timeoutsAlways specify a timeout9.3.4 Bulkheads9.4 Handling bad dataCross-site scripting and second-order attacks9.4.1 Don’t repair data before validation9.4.2 Never echo input verbatimSummary
10 Benefits of cloud thinking
10.1 The twelve-factor app and cloud-native concepts10.2 Storing configuration in the environment10.2.1 Don’t put environment configuration in code10.2.2 Never store secrets in resource files10.2.3 Placing configuration in the environment10.3 Separate processes10.3.1 Deploying and running are separate things10.3.2 Processing instances don’t hold state10.3.3 Security benefits10.4 Avoid logging to file10.4.1 Confidentiality10.4.2 Integrity10.4.3 Availability10.4.4 Logging as a service10.5 Admin processes10.5.1 The security risk of overlooked admin tasks10.5.2 Admin tasks as first-class citizensAdmin of log files10.6 Service discovery and load balancing10.6.1 Centralized load balancing10.6.2 Client-side load balancing10.6.3 Embracing change10.7 The three R’s of enterprise security10.7.1 Increase change to reduce risk10.7.2 Rotate10.7.3 Repave10.7.4 RepairSummary
11 Intermission: An insurance policy for free
11.1 Over-the-counter insurance policies11.2 Separating services11.3 A new payment type11.4 A crashed car, a late payment, and a court case11.5 Understanding what went wrong11.6 Seeing the entire picture11.7 A note on microservices architectureSummary
Part 3 Applying the fundamentals
12 Guidance in legacy code
12.1 Determining where to apply domain primitives in legacy code12.2 Ambiguous parameter lists12.2.1 The direct approach12.2.2 The discovery approach12.2.3 The new API approach12.3 Logging unchecked strings12.3.1 Identifying logging of unchecked strings12.3.2 Identifying implicit data leakage12.4 Defensive code constructs12.4.1 Code that doesn’t trust itself12.4.2 Contracts and domain primitives to the rescue12.4.3 Overlenient use of Optional12.5 DRY misapplied—not focusing on ideas, but on text12.5.1 A false positive that shouldn’t be DRY’d away12.5.2 The problem of collecting repeated pieces of code12.5.3 The good DRY12.5.4 A false negative12.6 Insufficient validation in domain types12.7 Only testing the good enough12.8 Partial domain primitivesNo double money12.8.1 Implicit, contextual currency12.8.2 A U.S. dollar is not a Slovenian tolar12.8.3 Encompassing a conceptual wholeSummary
13 Guidance on microservices
13.1 What’s a microservice?13.1.1 Independent runtimes13.1.2 Independent updates13.1.3 Designed for down13.2 Each service is a bounded context13.2.1 The importance of designing your API13.2.2 Splitting monoliths13.2.3 Semantics and evolving services13.3 Sensitive data across services13.3.1 CIA-T in a microservice architecture13.3.2 Thinking “sensitive”13.4 Logging in microservices13.4.1 Integrity of aggregated log data13.4.2 Traceability in log data13.4.3 Confidentiality through a domain-oriented logger APISummary
14 A final word: Don’t forget about security!
14.1 Conduct code security reviews14.1.1 What to include in a code security review14.1.2 Whom to include in a code security review14.2 Keep track of your stack14.2.1 Aggregating information14.2.2 Prioritizing work14.3 Run security penetration tests14.3.1 Challenging your design14.3.2 Learning from your mistakes14.3.3 How often should you run a pen test?14.3.4 Using bug bounty programs as continuous pen testing14.4 Study the field of security14.4.1 Everyone needs a basic understanding about security14.4.2 Making security a source of inspiration14.5 Develop a security incident mechanism14.5.1 Incident handling14.5.2 Problem resolution14.5.3 Resilience, Wolff’s law, and antifragilitySummary
index
Lists of Figures, Tables and Listings
List of IllustrationsList of TablesList of Listings

Content preview from Secure by Design

9 Handling failures securely

This chapter covers

Separating business and technical exceptions
Removing security issues by designing for failure
Why availability is an important security goal
Designing for resilience for a more secure system
Unvalidated data and security vulnerabilities

What is it that makes failures so interesting from a security perspective? Could it be that many systems reveal their internal secrets when they fail? Or is it how handling failure defines a system’s level of security? Regardless, recognizing that failures and security go hand-in-hand is incredibly important when designing secure software. This, in turn, requires understanding what the security implications are when making certain design choices. For example, ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781617294358Publisher Support Publisher Website Errata Page

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Secure by Design

by Dan Bergh Johnsson, Daniel Deogun, Daniel Sawano

9 Handling failures securely

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.