Designing Secure Software

Time to think about what goes into the thinking and design of the software.

Unit Goals

To understand how security plays a role in the design phase(s) of the software development lifecycle.

Software Development Lifecycle

The SDLC (software development lifecycle a.k.a systems development lifecycle) is really just a fancy term that highlights the fact that there are many phases in the life of a system (whether a physical product, information system, or similar thing). These phases vary depending on who is writing about it, and the phases overlap considerably, and sometimes are ill-defined. There is a lot of iteration as well. Perhaps it’s better to talk about “things we do when planning, building, deploying and maintaining” but hey, the term stuck.

What kind of lifecycle phases are out there? These are things like Ideation, Planning, (Requirements) Analysis, Design, Implementation, Code Review, Testing, Documentation, Integration, Deployment, Maintenance, Evaluation, Retirement, Disposal.

Read about the SDLC at Wikipedia.

Security concerns need to be applied everywhere within the SDLC. But how? Rather than me explaining it, read through this excellent presentation.

Exercise: Read the entire presentation and summarize the main points in your own bulleted list or short review or blog post.

Exercise: Seriously, study that presentation.

Here’s a talk by the author of that presentation, Jim Manico:

Secure Design

How do we “do security” in the early (analysis and design phases) of the SDLC? You should first be pretty well-versed in security concepts, principles, and some known vulnerabilities, and then design accordingly. The design phase in a SSDLC (security-focused software development lifecycle) goes roughly like this:

Identify assets (including what data is sensitive) and define security requirements (CIA)
Create a threat model (considering possible threats and misuse cases) and measure risk
Apply secure design principles throughout the design and specification of each module, class, etc.

You might also find that doing Domain-Driven Design helps.

Threat Modeling

All systems that manage assets in need of protection should have a documented threat model. When creating your Threat Model you take a holistic, global view of your system, and systematically document:

Your assets that might be valuable to others
What threats you might encounter (score with severity and likelihood)
What exactly each threat impacts (C, I, A, or a combination)
Who might attack you (attacker profile)
The potentially vulnerable parts of your system (attack surface), e.g., are there any weak points? Places where injection attacks can get in? Any buffers filled with user input? Any suspect communication links?
Impact of each threat
Prioritized strategies for defense, detection, mitigation, and recovery. Some threats a very expensive to deal with and may be rare. Focus on what is most possible. Always consider both severity and likelihood when preparing defenses.

Documenting the threats you might face and what you will do if you encounter them is valuable documentation! If you have a plan in place to respond and fix and deploy a patch, you’ll be able to do so when the time comes. Faster and more efficiently.

Learn more by reading OWASP Threat Modeling Post and the Wikipedia article on Threat Modeling, then (don’t miss this one) this CMU SEI blog article by Nataliya Shevchenko.

Exercise: Think of a web or mobile application you’d like to build. Write up a Threat Model, using one of the 12 methods in the Shevchenko article.

Remember, you have to think like an attacker. Learn how to do this, even if it is hard. Most developers want to build, not break. Ask your QA friends about breaking things.

Review of Secure Design Principles

Now that you have a threat model in place, the software can be designed. Remember that every fiber of your being should apply secure software design principles as you spec out, code, and test your creation. In no particular order, here’s a list of design principles.

Set Trust Boundaries (and when you do trust, do so reluctantly)
Design for Least Privilege
Maintain Integrity
Fail Fast
Audit
Don’t Rely on Secrets
Keep It Simple
Prevent Leaks
Avoid Security Through Obscurity
Defend in Depth (layers of defense)

Exercise: Describe each of these principles, orally, in your own words, to a friend, loved one, or rubber duck. (Why orally? Being able to articulate these principles is a good indicator you’ll be able to apply them well. Don’t worry if you can’t recall all of them just now. Look up the ones you don’t have a good handle on, and study them until you do.)

Domain Driven Design

Domain-driven design, or DDD, can help with designing security in.

Informally, DDD is motivated by facts such as:

Usernames are not just strings, they are usernames
Quantities are not just integers, they are quantities

Taking the time to understand your domain, and defining behaviors and constraints at the point of model definition prevents many vulnerabilities and keeps you from having to bolt-on ad-hoc security rules later.

Eric Evans created the whole DDD thing and he summarizes it this way:

Domain-Driven Design is an approach to the development of complex software in which we:

Focus on the core domain.

Explore models in a creative collaboration of domain practitioners and software practitioners.

Speak a ubiquitous language within an explicitly bounded context.

— Eric Evans, Domain-Driven Design Reference

DDD is about:

Understanding your domain model deeply, and representing it in code
Defining your domain model precisely and unambiguously, specifying exactly what your system should do (and by extension, what it should not do
Keeping the focus primarily on domain knowledge (and secondarily technical features), as you need your system to do the right thing

A good domain model is simple (focusing on the relevant parts and abstracting away certain details), understandable, with a precise vocabulary. It is high-level enough to be separated from low-level concerns, but low-level enough to be mapped easily to code.

CLASSWORK

Examples of domains are: Baggage handling, Compilers, E-commerce, Trading. What are some others? In a domain of your choice, what are some of the things the system should do? What are the points in the system that a user or external system could input bad data?

There can be a danger in developing a massively general system and then trying to shoehorn different domains into it. Sometimes you get lucky. But you should really start with domain knowledge.

The five main definitions (from the Reference):

Domain: A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.
Model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
Ubiquitous Language: A language structured around the domain model and used by all team members within a bounded context to connect all the activities of the team with the software.
Context: The setting in which a word or statement appears that determines its meaning. Statements about a model can only be understood in a context.
Bounded Context: A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.

Building Blocks:

Entities, value objects, aggregates
Domain events
Bounded contexts
Context mappings
Services and Modules
Repositories
Factories

Designing for Change:

Intention-Revealing Interfaces
Side-Effect-Free Functions
Assertions
Standalone Classes
Closure of Operations
Declarative Design
Conceptual Contours

Exercise: How does DDD tend to reduce vulnerabilities?

Summary

We’ve covered:

The Software Development Lifecycle
A review of secure design principles
Threat modeling
Domain-driven design