M

Secure by Design - Software Assurance

Security as a Concern, Not a Feature

  • View security as a concern that crosses the entire system, not as a feature you can switch on later.
  • A productive way to view security is as a cross-cutting concern that cuts across functionality rather than as a separate add-on.
  • Analogy: The robbery of Öst-Götha Bank, 1854 illustrates two views: a legal view and a technical view. Real security comes from treating security as a cross-cutting concern, not a list of features.

Core Attributes to Consider

  • Important attributes to balance in design:
    • Performance
    • Security
    • Maintainability
    • Usability
  • You should think security all the time as you design and implement.

Developer Mindset and Responsibility

  • ESSENTIAL NOTE: As a developer, you may feel that security is a burden you’d rather not handle.
  • You might think it would be better if a security expert was permanently on the team.
  • Questions raised:
    • Why do security tasks always get lower priority than other tasks?
    • Why are developers generally uninterested in security?
    • Experts tell developers to think more about security; why isn’t everyone doing it?
    • Why don’t managers recognize the need to include security experts in the team just as testers are included?
  • IMPORTANT: To efficiently and effortlessly create secure software, you need a mindset different from the one you might be used to.

Security as a Cross-Cutting Concern (Continued)

  • The traditional view often treats security as a set of features; the cross-cutting view treats security as a concern that must be addressed across every part of the system.

The CIA Triad: Confidentiality, Integrity, Availability

  • Classical information security triad (CIA):
    • Confidentiality: Keeping things secret that shouldn’t be public. Example: your healthcare record.
    • Integrity: Data should not change or should only change in authorized ways. Example: counting election results to ensure votes aren’t manipulated.
    • Availability: Data must be available in a timely manner. Example: Fire department needs location data immediately; delays can be deadly.
  • Notation: The triad can be summarized as \text{CIA} = (\text{Confidentiality}, \text{Integrity}, \text{Availability})

Defining Design

  • Design is used loosely and can mean different things in different contexts.
  • Questions posed:
    • Are API design and taking system architecture into account typical design activities?
    • Can domain modeling be considered a design activity?
    • Is choosing between final vs non-final object fields a design decision?

Defining Design (Continued)

  • One common thread: all these activities involve conscious decision-making.
  • Any activity that involves active decision-making should be considered part of the software design process and can be referred to as design.
  • Design is the guiding principle for how a system is built and applies at all levels, from code to architecture.
  • NOTE: Design includes any activity that involves active decision-making.

The Traditional Approach to Software Security and Its Shortcomings

  • The traditional approach assumes that everyone involved should be trained and experienced in software security.
  • Typical components of this view:
    • Developers should know about XSS and vulnerabilities in low-level protocols, and be familiar with the OWASP Top 10.
    • Testers should be trained in basic penetration testing techniques.
    • Business domain experts should be capable of discussing and deciding on software security.

A Simple Domain Object: The User Class

  • Consider a simple domain object representing a user in a web application with an ID and a username.
  • Listing 1.1 (conceptual): the user object could have issues because accepting any string as a username can enable XSS attacks.
  • XSS attack definition: an attacker uses a web application to send malicious code to another user via the application.

The Traditional Approach: Mitigation via Explicit Validation (Listing 1.2)

  • To mitigate the vulnerability under the traditional approach, you might add explicit security-focused input validation (as shown in Listing 1.2).
  • Problems with this approach:
    • Developers must explicitly think about security vulnerabilities while also delivering business functionality.
    • Requires every developer to be a security expert.
    • Assumes you can anticipate every potential vulnerability now or in the future.

The Pitfalls of the Traditional Approach

  • Explicitly thinking about security is problematic because developers prioritize functionality first.
  • Expecting every developer to be a security expert is unrealistic.
  • Even security experts cannot anticipate all potential vulnerabilities, especially the unknowable ones.

Driving Security Through Design

  • Rather than focusing on security as a primary task, shift focus to design with the goal of achieving high security through good design practices.
  • By focusing on design, you can achieve a high degree of software security without constantly thinking about security explicitly.

Making the User Secure by Design: Advantages

  • If design is central to development, security concepts become easier to adopt.
  • Business and security concerns gain equal priority in the view of both business experts and developers.
  • By choosing good design constructs, non-security experts can write secure code.
  • By focusing on the domain, many security bugs are addressed implicitly.

Design as a Natural Part of Software Development

  • When you focus on design, security becomes the concern of everyone, not just security experts.
  • Reasons for low security priority:
    • Security isn’t well understood by business or development teams.
    • Developers think security isn’t their concern.
    • Even when understood, security is often deprioritized behind user features and timeliness.

Non-Security Experts Naturally Write Secure Code

  • A secure-by-design approach allows non-security experts to write secure code because the design avoids insecure constructs.
  • Example reference: the Username class in Listing 1.4 with invariants that ensure only valid usernames are accepted.

Domain Focus Solves Security Bugs Implicitly

  • Security issues often seem scary; focusing on the domain makes the complexity disappear because the distinction between security bugs and ordinary bugs is erased when design is domain-focused.
  • Staying Eclectic: Combine a strong design focus with an eclectic approach to software security to create truly secure software.
  • Dealing with Strings, XML, and a Billion Laughs: Choosing data representations matters. Using overly generic types (e.g., representing a phone number as a string) can open security weaknesses, since a string can represent much more than intended.

The Billion Laughs Attack

  • The Billion Laughs attack is simple and effective: it exploits the expandability of XML entities by defining recursive definitions that expand into a huge memory footprint.
  • Listing 1.8 provides a compact XML payload (< 1 KB) that demonstrates the attack.

Applying a Design Mindset

  • Do not blame the root cause solely on how entities are expanded or on a faulty parser.
  • A malicious XML block (e.g., the Billion Laughs XML) should be rejected by the receiving system without parsing it, which is a desirable defense.

Summary (Page 19)

  • Security should be viewed as a concern to be met, not as a set of features to implement.
  • It is impractical to keep security at the forefront of every moment; design practices should guide toward secure solutions.
  • Any activity involving active decision-making is part of software design.
  • Design is the guiding principle for how a system is built and applies from code to architecture.

Summary Continued (Page 20)

  • The traditional approach struggles because it relies on developers to explicitly think about vulnerabilities while delivering functionality, requiring every developer to be a security expert and assuming they can foresee all potential vulnerabilities.
  • Shifting the focus to design enables a high degree of software security without constant explicit security thinking.
  • A strong design focus yields code that is more secure than the traditional approach.
  • Every XML parser is implicitly vulnerable to entity attacks because entities are part of the XML language.
  • Using generic types to represent specific data is a potential security weakness.
  • Choosing the XML parser configuration is difficult without understanding the underlying parser implementation.
  • Secure by design promotes security-in-depth by adding multiple layers of defense.