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.
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.
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.)
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.
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?
Recall Practice
Here are some questions useful for your spaced repetition learning. Many of the answers are not found on this page. Some will have popped up in lecture. Others will require you to do your own research.
In the early phases on the SDLC we must define not only use cases but also ________________
Abuse cases.
What things should you document in a Threat Model?
Your assets • Possible threats • Likely attackers • Vulnerable/weak parts of the system • Prioritized strategies for defense, detection, mitigation, and recovery.