'Secure by Design' principles include failures, exceptions

"Security is a quality aspect of a system. If your system is insecure, the quality is low," said Daniel Deogun, co-author of Secure by Design.

However, high-pressure challenges, such as strict deadlines from management and team leads, make many software developers and engineers more focused on making code work instead of ensuring security in the end product.

Another issue, co-author Dan Bergh Johnsson said, is that, "as a developer, you can become a bit overeager. When you've made the software work, it might do what you intended it to -- but also a little bit extra." This "little bit extra," he noted, could be harmless, or it could open security holes, which, over time, may create a patchwork of glitches that intelligent, patient hackers can exploit.

Deogun, Bergh Johnsson and co-author Daniel Sawano know firsthand the obstacles developers face -- especially those without a security background.

Here, the authors discuss the secure by design principles that are key in software development. They also explain why handling failures securely and understanding the concept of exceptions are vital components of a functioning and safe application.

Editor's note: This transcript has been edited for length and clarity.

Secure by Design

Click here to learn more about Secure by Design. Enter "TechTarget40" at checkout to receive a 40% discount on this title.

Visit Manning Publications to learn about other security and tech books.

Why is secure by design such an important software principle? What leads to software that is insecure by design?

Daniel Deogun: Sometimes, developers accidentally pick a data structure that is too generic. It may have solved their problem, but it also opened things that weren't intended. Take a string, for instance. You can put any kind of data inside a string. But, if you choose certain design patterns -- such as those we introduce in our book -- you can write code that is more explicit, which heightens the accepted input and thereby prevents injection attacks you would normally be able to do in a string.

Daniel Sawano: In the book, we provided principles and ideas that are easy for engineers and developers to relate to even if they aren't particularly security-minded. Our hope is that it will feel more natural for them, and therefore, it will be less effort when implementing security-promoting design principles. Since developers are promoting other properties of the system -- such as scalability or availability -- or simply doing the right thing in terms of business logic, they're actually not seen as an extra effort. It's just a natural thing to do, and you get security benefits.

Who is the book written for?

Deogun: Secure by Design is suitable for developers who have two to three years of experience but can be useful for people ranging from those at the beginning of their careers to those who have been doing it for 10 to 15 years.

Dan Bergh Johnsson: We tried to be intellectually strict with this book. We didn't want a book that had all the ideas we could gather about security but rather a book that conveys things we have had experience with in our professional lives. Readers will find out design patterns we have used with clients and in code bases that we have found productive in promoting the best security.

There's an excerpt of Chapter 9 on SearchSecurity that discusses handling failures securely. Why is this such an important consideration when making a design choice?

Deogun: When you ask developers -- mostly junior developers -- 'What's the outcome of this operation?' they tend to think about maybe half of the cases. Take an ATM, for example. An outcome could be that I got a $100 bill because I made a withdrawal. Another could be the machine rejected me because my balance was too low. Or maybe the machine can't connect to the bank. But, then, there are catastrophic failures to consider, where something totally unforeseen happens -- maybe the machine sets on fire. Modeling all of these can get crazy.

So, this is where exceptions come into play. How do those work?

If code cannot handle exceptional situations, systems will break and crack, revealing information which gives hackers clues.

Sawano: A lot of programming languages have the concept of exceptions -- which, if you listen to the name and think about it, it clearly means something exceptional has happened. When designing software, developers shouldn't treat standard outcomes as exceptions.

Bergh Johnsson: If we look at securing systems from a hacker's perspective, most of the info you get out of the system is when it stops working. If code cannot handle exceptional situations, systems will break and crack, revealing information which gives hackers clues. If we turn this situation inside out, there are benefits for developers. If we can build systems in a way that treats as many situations as possible as normal, then we will build normal, safe, well-designed code for it.

Take the ATM example. It's not exceptional that someone with funds in their account withdrew money; it's a perfectly normal thing do to. It's not exceptional that you cannot connect to the bank from the ATM; it's normal. You don't want the ATM to break down and have money extorted from the bank in strange ways. Designers must build those exceptional circumstances, treat them as something normal and build their code around that.

What final advice do you have for today's developers?

Deogun: One big takeaway would be for nonsecurity-minded developers to feel that they can write secure code and demystify old application security areas that aren't well understood. Hopefully, with the book, we provided them a small set of tools to begin that journey to writing secure code more easily.

Bergh Johnsson: I want people to know that security is not a separate question. Of course, there are people with security expertise, but security is not something developers should rely on someone else to do -- it is everyone's responsibility.