“Security is one aspect of the quality of a system. If your system is not secure, the quality is low,” said Daniel Deogun, co-author of Secure by design.
However, high pressure challenges, such as tight deadlines from management and team leaders, cause many software developers and engineers to focus more on how the code works instead of Ensure the security in the final product.
Another problem, said co-author Dan Bergh Johnsson, is that “as a developer you can get a little too impatient. When you’ve got the software up and running, it can do whatever you want – but also extra. . ” That “little extra,” he noted, could be harmless, or it could open security holes, which over time can create a patchwork of problems that smart and patient hackers can exploit.
Deogun, Bergh Johnsson, and co-author Daniel Sawano know firsthand the obstacles developers face, especially those with no security background.
Here, the authors discuss the safety-by-design principles that are key in software development. They also explain why to handle failures safely and understand the concept of exceptions are essential components of a functional and safe application.
Editor’s Note: This transcript has been edited for length and clarity.
Why is security by design such an important software principle? What leads to software unsafe intentionally?
Daniel Deogun: Sometimes developers accidentally choose a Data structure it’s too generic. It might have solved their problem, but it also opened up things that weren’t planned. Take a chain, for example. You can put any type of data in a string. But, if you choose certain design patterns – such as the ones we present in our book – you can write more explicit code, which increases the accepted input and thus prevents injection attacks that you would normally be able to do. in a chain.
Daniel Sawano: In the book, we have provided principles and ideas that are easy for engineers and developers to understand, even if they are not particularly concerned with security. Our hope is that it will feel more natural to them, and therefore, it will be less effort when implement design principles that promote safety. Since developers are promoting other properties of the system – such as scalability or availability – or just doing the right thing in terms of business logic, they’re actually not seen as extra effort. This is completely natural and you get security benefits.
Who is the book for?
Debug: Secure by design suitable for developers who have two to three years of experience but can be useful for people ranging from those just starting out in their careers to those who have been doing it for 10 to 15 years.
Dan Bergh Johnson: We have tried to be intellectually strict with this book. We didn’t want a book with all the insights we could gather on safety, but rather a book that expresses things that we have experienced in our professional life. Readers will find out design templates we have used with clients and in code bases that we have found productive to promote the best security.
There is a from chapter 9 on SearchSecurity which deals with the secure management of failures. Why is this such an important consideration when choosing a design?
Debug: When you ask developers, most junior developers, “What is the outcome of this operation?” They tend to think of maybe half the time. Take an ATM, for example. A result could be that I received a $ 100 bill because I made a withdrawal. Another could be the machine that 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 ignites. Modeling all of this can get crazy.
So that’s where the exceptions come in. How does it work?
Dan Bergh JohnssonAuthor
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 that something exceptional has happened. When designing software, developers should not treat standard results as exceptions.
Bergh Johnson: If we look at securing systems from a hacker’s perspective, most of the information you get from the system is about when it stops working. If the code cannot handle exceptional situations, systems will crash and crack, revealing information that gives hackers clues. If we turn this around, there are benefits for the developers. If we can build systems in a way that treats as many situations as possible as normal, then we’re going to build normal, safe, well-designed code for it.
Take the example of the ATM. It is not unusual for someone with funds in their account to withdraw money; it’s a perfectly normal thing to do. It is not unusual that you cannot log into the bank from the ATM; it’s normal. You don’t want the ATM to go down and money being extorted from the bank in some weird way. Designers have to build these exceptional circumstances, treat them like something normal, and build their code around it.
What final advice do you have for developers today?
Debug: A big takeaway would be that non-security-conscious developers think they can write secure code and demystify old application security areas that are not well understood. Fortunately, with the book, we’ve provided them with a small set of tools to start their journey to writing secure code more easily.
Bergh Johnson: I want people to know that security is not a separate issue. Of course, there are people who have security expertise, but security isn’t something developers should trust anyone else – it’s everyone’s responsibility.