Employ Security by Design

Learning Objectives

After completing this unit, you’ll be able to:

• Describe the threat modeling process.
• Create security acceptance criteria.

Employ Security by Design

Security by design (SBD) is a software engineering protocol that is a core component of the secure development lifecycle (SDL) model. SBD means that software engineers have designed the software to be secure from the outset. While in the past it was common to leave security features until late in the development cycle, it has become clear that designing from the start with security in mind reduces the likelihood of flaws that might compromise an organization’s security. SBD is more important than ever as the industry moves to cloud computing and increasingly adopts other new technology.

Implementing SBD means you need to start with secure architecture. It’s vital to make architectural design decisions based on known security tactics and patterns, some of which we talk about in this unit. These include applying defense in depth, using least privilege, and minimizing attack surfaces. You learn more about each of these below.

At the design stage, it’s important to take into account the specifics of your work: its environment, potential risks, severity, and impact. You can accomplish this by creating a threat model. 

Model Your Threats

As you design awesome work for your customers, think about potential issues in terms of security. Instead of speculation, it helps to use a formal process called threat modeling. 

There are a number of ways to model threats. These are described in greater detail in the Threat Modeling module. In general, threat modeling involves five steps.

1. Agree on security objectives.
2. Describe your architecture by creating a data-flow diagram.
3. Identify the threats to your project by examining your organization’s assets and vulnerabilities.
4. Identify mitigations to the threats (possible and verified) that you found in your project.
5. Build and validate the defenses for your project.

Once you’ve modeled your threats, it’s time to design and make security a foundational part of your development project. 

Design and Build Securely

So you’ve finished your security assessment and modeled your threats. How exactly do you go about building products that are SBD? You take these basic security precautions into account while doing your work.

Apply defense in depth. Design multiple layers of security like multi-factor authentication (MFA) and add additional internal authentication mechanisms like mutual Transport Layer Security (TLS) to help stop attackers if they do manage to compromise part of a system. 

Use least privilege. Give users, applications, systems, and other components only the most restrictive permissions needed to do the job and nothing more. This principle prevents attackers from performing administrative actions if they've compromised a normal user account. 

Use secure defaults. Configure your software environment to have secure settings by default that users can opt out of, instead of requiring them to opt in to secure settings. 

Minimize attack surface. Every port you open, every external library you use in your code, and every user you give access to your data expands the attack surface. Reduce overall risk by minimizing your attack surface. The OWASP organization has a good primer on Attack Surface Analysis. 

Use a positive security model. A positive security model or safelist approach is one that defines what is allowed and rejects everything else. Use this approach to make sure you only allow the known good instead of trying to disallow the possible bad.

Fail securely. Implement decision logic that puts systems into a secure state when errors occur. Secure error handling design prevents the execution of any actions or information disclosure that can be used by an attacker.

Protect customer data. Customers own their data and should have control over it. It’s important to make sure that customer data is always secure, both at rest and in transit. Use encryption when you are storing customer data and when you are transporting it. 

Don’t trust external data or input. Data must always be handled as if it is untrustworthy. Best practices for handling external data include inspecting and sanitizing all external input before processing. They also include implementing logic that handles unexpected data payload in every processing service, even if the data has already been sanitized and verified. 

Create Security Acceptance Criteria

You’ve identified threats and mitigations. Now you need to translate the threats into acceptance criteria based on the security principles. These criteria are usually called definitions of done. 

Acceptance criteria must be expressed clearly, in simple language, without ambiguity as to what the expected outcome is. It defines what is acceptable and what is not acceptable. The criteria must be testable—easily translated into one or more manual or automated test cases.

Regardless of how you manage your work, it’s imperative for you to follow through with addressing the security risks you identified. Otherwise, the time you invest in threat modeling is wasted, and you’re putting your customer data, intellectual property, or whatever you’re trying to protect at risk.

Implement the Security Acceptance Criteria

Most of the work in creating a software project happens during the development stage in the OWASP SDL framework. This is also a phase your team returns to repeatedly while you implement the security acceptance criteria you came up with during design.

These criteria can include security mitigations, bug fixes, or feature changes you identify during the design stage as you create your product or service. You can also perform security testing as part of the functional tests you run to ensure your product works as designed.  

Knowledge Check

Ready to review what you’ve learned? The knowledge check below isn’t scored—it’s just an easy way to quiz yourself. To get started, drag the term in the left column next to the matching description on the right. When you finish matching all the items, click Submit to check your work. To start over, click Reset.

Great work! Now that you understand how to model threats and to design and build securely to address those potential vulnerabilities, let’s take a look at how to test and verify the security of your development.  

Resources

• PDF: Open Web Application Security Project (OWASP): Making the Web Secure by Design
• OWASP: Attack Surface Analysis
• Trailhead: Threat Modeling Fundamentals
• Trailhead: Develop Secure Web Apps

Quiz

Omar’s team is about to create a new version of their Mars Explorer application. They want to make sure they are designing the application securely.