Veze, linkovi
Kompjuter biblioteka
Korpa
Secure by Design

Zaštita i sigurnost Zaštita i sigurnost

Secure by Design

Autor: Dan Bergh Johnsson, Daniel Deogun, Daniel SawanoForeword by Daniel Terhorst-North
Broj strana: 400
ISBN broj:
Izdavač: MANNING PUBLICATIONS MANNING PUBLICATIONS
Godina izdanja: 2019.

                 
Twitter   Facebook   Linkedin   Pinterest   Email
                 
Predlog za prevod

 

Kupite na Amazonu

 

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. From the Foreword by Daniel Terhorst-North 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. 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

About the reader

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

About the authors

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.

 

Budite prvi koji će ostaviti komentar.

Ostavite komentar Ostavite komentar

 

Preporučujemo

Zaštita od zlonamernih programa (Malware analysis)

Zaštita od zlonamernih programa (Malware analysis)

Cena: 2640 rsd
Popust i do: 1716 rsd

CompTIA Security+: SY0-601 vodič za sertifikaciju

CompTIA Security+: SY0-601 vodič za sertifikaciju

Cena: 2750 rsd
Popust i do: 1788 rsd

Veze, linkovi
Linkedin Twitter Facebook
 
     
 
© Sva prava pridržana, Kompjuter biblioteka, Beograd, Obalskih radnika 4a, Telefon: +381 11 252 0 272