Secure by Design

Security by design means treating security as an equally important requirement right from the start of software development instead of retrofitting it at the end of the project. In concrete terms, this means building multi-layered defenses, not inventing your own security technology, enforcing secure default settings and embedding threat modeling firmly into the development process.

Key Takeaways

• Using security mechanisms individually is not enough: relying on a single layer gives attackers a free pass through the entire system after the first intrusion.
• Building your own encryption or authentication solutions is a typical mistake, because even professionally developed security technology has vulnerabilities that only intensive testing can uncover.
• Threat modeling does not have to be complicated: it is enough to call the team together and ask in a structured way what is valuable, who wants it and what an attacker might do.
• Testers have a natural role in the security process because they systematically ask what can go wrong and make vulnerabilities visible before they become disasters.

Security belongs at the beginning, not the end

Treating security as a downstream task is the most common mistake in software development. If you only think about security in the last ten percent of a project, you only get ten percent security.

Security belongs to the same class of properties as performance, reliability and availability. These aspects are clear to everyone in theory, but in practice they are put off until later, and later never comes. Any tester can confirm that this plan doesn’t work.

Interest in security has changed. Eoin Woods, who started giving talks on the subject around ten years ago, remembers rooms with an audience of five, all of them security people. Today there are people from software development who are actually interested in the topic. This shift is the basis for being able to establish security at an early stage.

Why security experts and development teams talk past each other

The rift arises because both sides speak different languages. Software developers often only know security in the abstract: authentication, authorization, auditing as terms, without concrete implementation.

Security engineers are clever specialists who do exactly that all day long. However, they often come from the infrastructure sector and know little about modern software provision. When the two meet, the expert quickly overwhelms the team with complicated material that supposedly has to be implemented immediately, otherwise disaster looms.

This all-or-nothing logic is misleading. In safety, nothing is absolute. Every decision is a trade-off, and the task is to find the right balance, not to demand maximum effort.

Design principles make security tangible

A manageable set of design principles helps teams more than a complete collection. Good principles are easy to understand, easy to remember and get developers thinking about security sooner.

In his search, Eoin Woods came across collections ranging from eight or nine points to several hundred. Very large collections are all correct in content, but useless: Nobody works with hundreds of rules in everyday life. The practical way is in the middle, with a set that covers most of what software teams need to know.

I firmly believe that design principles help make design decisions. Eoin Woods

Layered defense

Never rely on a single security mechanism. Attackers today are sophisticated enough to defeat a single mechanism, be it encryption or an authentication system.

Almost every mechanism has vulnerabilities, or mistakes are made in the application. Several independent layers ensure that an attacker does not possess the entire system once he has overcome a hurdle. In highly secured systems, such as government agencies, each layer has its own mechanisms. If you break through one layer, you are faced with the next. The aim is to make a break-in expensive.

Don’t invent your own security technology

Building your own security technology is much harder than it looks. Many less experienced developers underestimate the effort involved: they want to write their own password vault or wonder how hard encryption can be.

The same applies to integration into systems such as OAuth for authentication and authorization. Find a library that does it. Even security technology built by professionals has weaknesses. Experienced security testers take every new product apart immediately and always find something. The probability that a self-built solution is cleaner is close to zero. In addition, there is the extra effort that a project does not need.

When choosing between open source and commercial libraries, there is no clear winner. Open source offers transparency and many independent researchers who check the code. In certain markets, a closed source solution can be the better choice if you ask the providers the right questions.

Be careful, but trustworthy

Don’t accept unauthorized or unauthenticated network connections, and be careful what you let into your system. This applies to connections as well as data and the building blocks you use to assemble the system.

There are numerous security gaps where malicious data can be infiltrated. Equally important is the question of what you are building from: open source components, but also commercial libraries and platforms. How secure are they, and how would you even notice a vulnerability?

Secure default settings and how to deal with errors

Software must be delivered with secure default settings and fall into a secure state in the event of an error. Default passwords are an old but persistent problem.

Earlier Oracle systems came with influential accounts and fixed default passwords. The cliché was: if you have Oracle, you have a Scott Tiger account, i.e. a user “Scott” with the password “Tiger”. Practically any system could be opened via this demo user. The pattern lives on: open source software, cloud demos and even enterprise-class network hardware are delivered with preset users and passwords because it’s convenient. Convenient and insecure at the same time.

The second part concerns behavior in the event of an error. A database vendor, known for performance and availability, built in a tamper-proof audit trail at the customer’s request. However, the engineers deactivated the logging as soon as the memory was full or showed a malfunction and simply continued processing. Only a beta customer stopped this: the audit trail was full and processing continued without an audit. From a throughput and availability perspective, the audit seemed unnecessary. But it wasn’t.

Similar questions arise with message-driven systems after a complex failure. When restarting: Does the system wait until all security services are available and end-to-end authentication is guaranteed? Or does it start processing as soon as the opportunity arises? The second option opens a window that nobody wanted to open.

Typed interfaces against the lowest common denominator

The easiest way to move data between systems is also the most dangerous: turn everything into a string. This method rejects nothing and is therefore tempting.

This is precisely where the loophole lies. Attackers send faulty strings that the string processor waves through. The damage only occurs when they are translated into another format, from a denial of service to exploits for remote commands. Anyone who reads in large amounts of unformatted data without checking it carefully creates a considerable risk.

Strongly typed interfaces are the more secure answer, but they come at a price. They are more complex to develop, less flexible and more difficult to develop further. This trade-off needs to be made consciously, especially in landscapes with many connected applications and APIs, in which a problem introduced would otherwise permeate all systems.

How security comes into the development process

Design principles are aimed at the people who design. The bigger question is how the whole team works together to deliver secure software. The answer is a secure software delivery cycle across the entire lifecycle.

You don’t have to invent this cycle yourself. There are established models, such as OWASP, an organization with extensive resources and a well-developed, widely used secure development cycle. Authorities also offer such models. Start with a proven model and adapt it to your context instead of starting from scratch.

Security is one of the non-functional requirements, and this is where the trap lies: if user stories have already been written, it is often too late. That’s why security stories belong early in the process.

Perpetrator reports and threat modeling

A simplified form of security analysis are perpetrator reports: How could someone attack this system? They are the accessible version of threat modeling that occurs in every secure development cycle.

Threat modeling sounds complicated, but it’s not. The team sits down and works through three questions in a structured way:

• What do we have that is valuable? A piece of information, a financial transaction or an action that someone wants to activate or deactivate.
• Who would consider it valuable?
• How would this attacker go about getting the valuable thing?

The procedure is similar to planning for high availability: you sit down and work out what could go wrong and what would happen in each of these cases. If you go through this process, you will have a much better idea of how robust your system really is. Adam Shostak’s book is considered a classic on the subject, but there are also other good works. The most important advice from the experts: don’t make things unnecessarily complicated.

Zero-day vulnerabilities cannot be designed away

There is no single design trick against zero-day vulnerabilities, only the interplay of several principles. If you rely on a single component and it has a zero-day vulnerability, you will be attacked.

This is where multi-layered defense pays off directly. Then there is the operational side: do you have a strategy for keeping your components up to date? This is difficult in the open source age. Some ecosystems, such as that of Node.js, consist of very finely granulated parts. Without automated support, you can’t keep track of vulnerabilities.

Complete control over zero-days is not possible because there is a black market for such exploits and their existence is difficult to detect. What remains is to be consistent within your own sphere of influence: to know what is in the system and to automatically monitor whether the components have vulnerabilities.

Testers are the natural advocates of security

Testers think about what could go wrong as part of their job. This makes them the most valuable stakeholders when it comes to anchoring security in the project, because most others do not do exactly that.

Software architects also think about risk, but are under pressure to deliver new features or focus on a specific quality characteristic like throughput for two or three sprints. They know that security is important, but their minds are elsewhere. This is exactly where the tester steps in when he notices that a new function bypasses the security check.

For this to work, teams need to encourage testers to ask such questions. There is a risk that the tester will feel unpopular for asking the difficult question. The right response is not defensiveness, but gratitude: without this question, the team would have made a mistake.

The DevOps idea helps because testers join the team earlier. In the past, the tester was the last person to see the software and could only determine what had been done.

Who you involve early on

In addition to the tester, the security engineer should be at the table, ideally someone with experience in application security and infrastructure. If you invite them to the joint threat modeling and ask the right questions, they will bring up points that no one in the team had thought of.

It makes sense to set up an internal pen testing team early on, not just for the final tests. Early penetration tests uncover everything that goes wrong. It may be fine at the moment, but suddenly everyone thinks that this part must be secure and it isn’t yet. Even the product owner then sometimes realizes that security is a bigger issue than they thought.