Secure by Design
FREE
You can see this entire book for free.Click the table of contents to start reading.
A practical, actionable handbook. Not just a call to arms about treating security seriously as a design activity...it also provides a raft of real examples, worked through from design considerations to actual code listings.
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.
Table of Contents takes you straight to the bookdetailed table of contents
Part 1: Introduction
1 Why design matters for security
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
Summary
2 Intermission: The anti-Hamlet
2.1 An online bookstore 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
Summary
Part 2: Fundamentals
3 Core concepts of Domain-Driven Design
3.1 Models as tools for deeper insight
3.1.1 Models are simplifications
3.1.2 Models are strict
Some terminology
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
Repositories
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
Summary
4 Code constructs promoting security
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
Access tokens
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
Summary
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
Details of the Password class
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
Summary
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
The history of the JavaBeans set/get naming conventions
6.2.4 Construction with a fluent interface
Nonfluent fluent interface
6.2.5 Catching advanced constraints in code
6.2.6 The builder pattern for upholding advanced constraints
Constructors galore
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
A bad date
6.3.3 Securing the integrity of collections
The trouble of modifiable items in a list
Summary
7 Reducing complexity of state
7.1 Partially immutable entities
7.2 Entity state objects
7.2.1 Upholding entity state rules
Online gambling sites and free money
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
How databases make entities lock
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
Summary
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
Testing with input that causes eventual harm
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
Summary
9 Handling failures securely
9.1 Using exceptions to deal with failure
9.1.1 Throwing exceptions
Be careful using findFirst
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
Always specify a timeout
9.3.4 Bulkheads
The Reactive Manifesto
9.4 Handling bad data
Cross-site scripting and second-order attacks
9.4.1 Don’t repair data before validation
9.4.2 Never echo input verbatim
XSS Polyglots
Summary
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
Principle of least privilege
10.3.2 Processing instances don’t hold state
Backing services
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
Admin of log files
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
Advanced persistent threats
10.7.2 Rotate
10.7.3 Repave
Containers and virtual machines
10.7.4 Repair
Summary
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
Summary
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
What about builders?
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
No double money
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
Summary
13 Guidance on microservices
13.1 What’s a microservice?
A distributed monolith
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�
Passing data over the wire
13.4 Logging in microservices
13.4.1 Integrity of aggregated log data
13.4.2 Traceability in log data
Semantic versioning
13.4.3 Confidentiality through a domain-oriented logger API
Summary
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?
Context-driven testing (CDT)
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
Distinguishing between incident handling and problem resolution
14.5.1 Incident handling
14.5.2 Problem resolution
14.5.3 Resilience, Wolff’s law, and antifragility
System theory
The tragedy of penetration tests and going antifragile
Summary
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
- customers also bought these items
- Cloud Native Patterns
- Docker in Action, Second Edition
- Microservices in Action
- HTTP/2 in Action
- Microservices Security in Action
- Understanding API Security
- customers also bought these items
- Microservices in Action
- Microservices Patterns
- Kubernetes in Action
- Cloud Native Patterns
- The Design of Web APIs
- Docker in Action, Second Edition
Prices displayed in rupees will be charged in USD when you check out.
placing your order...
Don't refresh or navigate away from the page.FREE domestic shipping on three or more pBooks