Secure by Design: Why Design Matters for Security

Viewing Security as a Concern

• Security should be viewed as a concern to be met rather than a set of features to be implemented. A feature is something additive, while a concern is something that must be considered across the entire development process.

• The robbery of Öst-Götha Bank in $1854$ illustrates the duality of perspectives: one legal and one technical. To achieve real security, developers must move away from the "feature list" mentality and view security as a cross-cutting concern—one that cuts across all functionality within the system.

• It is impractical to expect developers to keep security at the top of their minds at all times while also focusing on complex business logic. Instead, design practices should be established that naturally guide developers toward more secure solutions.

The CIA-T Triad: Categorizing Security Concerns

Classical information security is typically categorized using the triad of Confidentiality, Integrity, and Availability (mnemonic: CIA):

• Confidentiality: This is the most common association with security. It involves keeping information secret from unauthorized parties. A primary example is a healthcare record, which contains highly sensitive private information that must remain confidential.

• Integrity: This refers to the concept that information must not change, or must only change in authorized, specific ways. An example is counting election results; security in this context ensures that the votes (the data) have not been manipulated or altered.

• Availability: This ensures that data is accessible in a timely manner. For example, a fire department requires the location of a fire immediately. If the information is delayed, the security concern of availability is not met, potentially leading to catastrophic failure regardless of if the data remained secret or accurate.

Defining Design and Decision-Making

• Design is often used loosely, but in the context of secure software, it is defined as any activity involving active, conscious decision-making.

• Design is not restricted to architecture or high-level diagrams; it is the guiding principle for how a system is built and applies to all levels, from low-level code implementations to system-wide architecture.

• Examples of Design Activities:

  • API design and considering system architecture.

  • Domain modeling.

  • Micro-decisions like choosing whether a field in an object should be declared as final or non-final.

The Traditional Approach to Software Security

• The traditional approach operates on the belief that everyone in the development process—developers, testers, and business experts—needs to be specifically trained and experienced in software security.

• Developer Requirements: Under this model, developers are expected to know the OWASP Top $10$ perfectly, understand vulnerabilities in low-level protocols, and be aware of various attacks like Cross-Site Scripting (XSS).

• Tester and Expert Requirements: Testers should be trained in basic penetration testing, and business domain experts must be capable of making security-related decisions.

• This approach is illustrated in Figure $1.2$, showing a set of specific tasks and actions developers must adhere to manually.

Shortcomings of the Traditional Approach

• Cognitive Load: Developers must explicitly think about security vulnerabilities while simultaneously focusing on solving complex business functionality. The main focus will always naturally be on the functionality being implemented.

• The Expertise Gap: It requires every developer to be a security expert. This is unrealistic, as not every developer can be an expert in all specialized fields like JVM performance, UX design, or security. Current industry standards do not generally support this level of universal expertise.

• The Unknowable: Even a team of experts can only write countermeasures for known vulnerabilities. It assumes the person writing the code can anticipate every potential future vulnerability.

• XSS Example (Listing $1.1$ and $1.2$): A simple user object with a username (Listing $1.1$) is vulnerable to XSS if it accepts any string. The traditional fix (Listing $1.2$) introduces explicit input validation code. This is problematic because it relies on the developer remembering to add these checks every time and manually considering attack vectors.

Driving Security Through Design

• Rather than maintaining security as a constant explicit focus, the "Secure by Design" approach focuses on software design and high standards of creation.

• Shifting focus to design allows for a high degree of security without the need to constantly think about security explicitly. Secure constructs become a natural part of the development process.

• The Benefits of Secure by Design:

  • Interests and Competence: Design is central to what developers already enjoy and excel at, making these concepts easier to adopt than dry security checklists.

  • Equal Priority: By focusing on design, business and security concerns gain equal priority in the eyes of business experts and developers alike.

  • Non-Experts Write Secure Code: Choosing good design constructs allows those who are not security experts to write secure code because the design implicitly avoids insecure constructs.

  • Domain Focus: Focusing on the business domain allows many security bugs to be solved implicitly as they are treated as domain-logic errors or "ordinary bugs."

Implementing Invariants: Listing $1.4$

• A "Secure by Design" approach to the username vulnerability (Listing $1.4$) involves creating a Username class instead of a generic string.

• This class uses invariants to ensure that only valid usernames can ever exist in the system. The design itself prevents malicious data from entering the domain, effectively neutralizing many attack vectors without the developer needing to explicitly think about the "security" aspect of the input.

Primitive Obsession and Generic Data Types

• A common design flaw is the tendency to use generic data types (like String) for specific domain concepts (like phone numbers).

• From a security perspective, this is dangerous because generic types can represent almost any kind of data. Using a generic string for a phone number opens the door for security weaknesses that more specific design types would catch automatically.

Case Study: The Billion Laughs Attack

• The Billion Laughs attack is a simple but effective XML-based attack defined in Listing $1.8$ .

• Mechanism: It exploits the expandability property of XML entities by creating recursive definitions that expand into a massive memory footprint upon parsing.

• Scale: A small XML block, less than $1\,KB$ in size, can crash a system by exhausting its memory resources.

• Design Perspective: The root cause is not a faulty parser; the expansion is technically in accordance with the XML specification. Every XML parser is implicitly vulnerable because entities are part of the XML language.

• The Design Fix: A design-oriented mindset focuses on rejecting the malicious block without parsing it or configuring the parser differently. However, choosing the correct configuration is difficult without deep knowledge of the underlying implementation.

Questions & Discussion

• The Developer Burden: Developers often feel security responsibility is a burden they'd prefer to offload to permanent security experts on the team.

• Priority Issues: Why do security tasks consistently get lower priority than other tasks? Even when understood, security is often viewed as something that can be added later, unlike user features.

• The Education Gap: Experts repeatedly tell developers to think about security, yet universal adoption is missing. Why don't managers include security experts in the same way they include testers?

• The Mindset Shift: Efficiently creating secure software requires a fundamental shift in mindset away from traditional habits.

Summary of Secure by Design Principles

• Security is a concern, not a feature list.

• Design applies from architecture down to individual lines of code.

• Shifting focus to design achieves high security without constant cognitive overhead.

• Secure by design promotes security in-depth by layering protections.

• Design constructs should implicitly avoid insecure states, allowing non-experts to produce robust software.