Secure by Design 

How can you incorporate security principles into the development process at an early stage, instead of somehow tinkering them in afterwards? Eoin talks about his experiences from the past and shows how security awareness has grown over the years. He emphasizes the importance of principles such as “Defense in Depth” and the use of secure default settings. We also talk about the challenges of keeping up with the latest security threats and the value of involving security engineers and testers early in the project.

“If you start thinking about security in the last 10% of your project, you’re going to get 10% security.” – Eoin Woods

Eoin Woods is Chief Engineer at Endava, where he is responsible for skills development, innovation and new technologies. In his previous career he developed databases and built security software. Outside of work, he is interested in software architecture, software security, DevOps and software energy efficiency. He is a frequent conference speaker, has co-authored three books on software architecture, and was awarded the 2018 Linda Northrup Award for Software Architecture from the Software Engineering Institute at CMU.

Highlights of this Episode:

• Security as a first-class citizen in the development process
• Software developers lack in-depth knowledge of security, which is only slowly changing.
• The “Defense in Depth” concept for protecting a system includes
• Established libraries instead of in-house developments.
• The use of OWASP resources.
• The challenge of zero-day vulnerabilities and the importance of keeping components up to date.

Further links:

• Eoins Website
• Continuous Architecture in Practice
• Software Systems Architecture

Security by Design implementieren

In this episode, I discuss the concept of “Security by Design” with Eoin. We explore principles such as “Defense in Depth”, avoiding custom security solutions, and incorporating security into the entire software development lifecycle. This conversation emphasizes the importance of proactive security measures in software development.

Introduction to Security by Design

Hello and welcome to a new episode of the Software Testing podcast! Today we have a special episode recorded live from the OOP 2024 conference in Munich. I’m Richie, your host, and our guest today is Eoin Wutz. We had an interesting conversation about implementing ‘Security by Design’ in software development. This topic is very close to my heart because as we all know, testing for security is often done too late in the process. Then it’s like trying to put the baby back in the well - it’s already too late. So let’s explore how we can integrate security right from the start.

The change in security mentality

Eoin began by talking about his journey into security technology. He recalled how difficult it was ten years ago to get people interested in security. Back then, he often found himself sitting in rooms with only a handful of interested people - all specializing in security. Today, however, things have changed dramatically. The rooms are now full of people interested in security. This change means not only a shift in awareness, but also a recognition of the critical role that security plays in different areas - be it performance, resilience or availability.

Principles for early security integration

One important point Eoin emphasized was the importance of integrating security early in the development process. If you only think about security in the last 10% of your project,” Eoin warned, “you will only get 10% security. Many software engineers lack a solid background in security; however, some universities are beginning to close this gap by offering more security-related courses as early as freshman year. Despite this progress, there is still a divide between software developers and security engineers - each group speaks its own language and has its own priorities.

Defense in depth and avoidance of special solutions

Eoin highlighted several principles, starting with “defense in depth”. With today’s sophisticated attackers, relying on a single layer of security such as encryption or authentication is naïve. Multiple layers ensure that even if one layer is breached, the others will still hold. Another principle he emphasized was the avoidance of bespoke security solutions. It may seem tempting for engineers to build their own encryption systems or password vaults, but this comes with risks. Professionals rigorously test industry-standard solutions; home-grown solutions are rarely subjected to such scrutiny.

Navigating between open source and closed source solutions

When it comes to choosing between open-source and closed-source solutions for encryption and other security measures, Eoin points out that context is very important. Open-source solutions offer transparency and are constantly reviewed by independent researchers. However, closed-source solutions can sometimes be superior depending on the specific market requirements or applications. The most important thing is to ask vendors the right questions and choose what works best for your project.

Secure software development life cycle (SDLC)

Design principles are aimed at designers,” Eoin explained when discussing how to incorporate security into the software development process. He recommended adopting an industry-standard secure software development lifecycle (SDLC) model, such as those from OWASP or various government agencies. These models guide teams in integrating security at every stage - from requirements gathering to deployment. Adapting these models to specific project requirements can help organizations systematically eliminate potential vulnerabilities early on.

Bringing security into daily practice

Towards the end of our conversation, we touched on practical steps teams can take to make security a daily practice and not just an afterthought. One effective approach is to use “security user stories” or “abuser stories” during threat modeling sessions. This involves asking critical questions about what could go wrong and who could exploit the vulnerabilities of the system. By involving testers early in the development process, potential problems can be identified before they become entrenched. Finally, the involvement of knowledgeable application security engineers during design reviews and threat modeling sessions can provide invaluable insight.