1 Why design matters for security

 

This chapter covers

  • Viewing security as concerns, not features
  • Design and why it’s important for security
  • Building in lots of security by focusing on good design
  • Addressing the Billion Laughs attack

Imagine yourself setting up a typical software project. You assemble a team of developers, testers, and domain experts and start outlining the key requirements. With input from stakeholders, you come up with a list of important attributes: performance, security, maintainability, and usability. As with many software projects, quality takes top priority, time to market is of the essence, and you need to stay within budget. You decide to be proactive and add security features to your backlog, and some of the other team members come up with a good list of security libraries you can use in your code. After the initial planning, you get the project up and running and start implementing features and business functionality. The team is motivated and delivers features at a good pace.

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

sitemap