How to Create Application Security Design

Requirements

Course_Overview_and_Objectives

Narration
Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of application data,
software applications must be engineered with security in mind from inception through deployment. If you are not thinking about security in the design
phase,
and if you are not driving your application design with security in mind, your application will be less secure in production, and any security efforts you take at
that point will be more expensive.
Use security requirements to focus your design and development efforts on the most important objectives from a security perspective.
During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security impact.
This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best way to create secure software with
minimal disruption to your development process.
In this course, you will learn to integrate security engineering in your development life cycle.
You will also learn to define security requirements and objectives during the requirements phase of your application development.

Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of application data, software
applications must be engineered with security in mind from inception through deployment.
If you are not thinking about security in the design phase, and if you are not driving your application design with security in mind, your application will be
less secure in production, and any security efforts you take at that point will be more expensive.
Use security requirements to focus your design and development efforts on the most important objectives from a security perspective.

Page 1 of 65
 How to Create Application Security Design
Requirements

During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security impact.
This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best way to create secure software with
minimal disruption to your development process.
In this course, you will learn to integrate security engineering in your development life cycle. You will also learn to define security requirements and
objectives during the requirements phase of your application development.

On Screen Text

Course Overview and Objectives

Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of
application data, software applications must be engineered with security in mind from inception through deployment. If you
are not thinking about security in the design phase, and if you are not driving your application design with security in mind,
your application will be less secure in production and any security efforts you take will be more expensive.

Use security requirements to focus your design and development efforts on the most important objectives from a security
perspective.

During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security
impact. This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best
way to create secure software with minimal disruption to your development process.

Course Objectives:
• Integrate security engineering in your development life cycle.
• Understand how to define security requirements and objectives during the requirements phase of your application
development.

Page 2 of 65
How to Create Application Security Design
Requirements

Module_Overview_and_Objectives

Narration
This module explains the path to security maturity and provides an overview of security engineering.
It also explains how you can adopt a secure development process.
After completing this module, you will be able to apply the application security maturity (ASM) model to your development process,
understand the security-engineering process, and describe the key security-engineering activities you can use to integrate security in your development life
cycle.
Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of application data,
software applications must be engineered with security in mind from inception through deployment. If you are not thinking about security in the design
phase,
and if you are not driving your application design with security in mind, your application will be less secure in production, and any security efforts you take at
that point will be more expensive.
Use security requirements to focus your design and development efforts on the most important objectives from a security perspective.
During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security impact.
This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best way to create secure software with
minimal disruption to your development process.
In this course, you will learn to integrate security engineering in your development life cycle.
You will also learn to define security requirements and objectives during the requirements phase of your application development.

Page 3 of 65
 How to Create Application Security Design
Requirements

Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of application data, software
applications must be engineered with security in mind from inception through deployment.
If you are not thinking about security in the design phase, and if you are not driving your application design with security in mind, your application will be
less secure in production, and any security efforts you take at that point will be more expensive.
Use security requirements to focus your design and development efforts on the most important objectives from a security perspective.
During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security impact.
This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best way to create secure software with
minimal disruption to your development process.
In this course, you will learn to integrate security engineering in your development life cycle. You will also learn to define security requirements and
objectives during the requirements phase of your application development.

On Screen Text

Module Overview and Objectives

Module Overview
This module explains the path to security maturity and provides an overview of security engineering. It also explains how you
can adopt a secure development process.

Module Objectives
After completing this module, you will be able to:
• Apply the application security maturity (ASM) model to your development process.
• Understand the security-engineering process.
• Describe the key security-engineering activities you can use to integrate security in your development life cycle.

Page 4 of 65
How to Create Application Security Design
Requirements

Understanding_the_ASM_Model

Narration
The application security maturity (ASM) model was developed by collecting information from organizations about their security progress over a ten-year
period.
Results of these inquiries showed that organizations tend to follow a similar path,
which breaks down into three distinct phases.
The first phase is called the Panic Scramble, where organizations realize that they have to do something about software security. This realization typically
occurs when a company has a data breach,
one of their competitors has a data breach, or a new regulation requires compliance in application security.
In response to that panic, organizations invest in tools and technology. So, they mature rapidly on the tools and technology axis, but not on the people and
process axis until they reach an inflection point
and enter the second phase—the Pit of Despair. Here, organizations realize that they do not know how to use their expensive tools. Security teams are
running vulnerability scans,
but developers don’t know how to interpret the results and act on the reports, so they keep finding the same problems over and over. Organizations get
discouraged and tool usage drops.
However, eventually they develop details along the people and process axis, and the organization slowly becomes more mature until they hit the second
inflection point.
Here, they start to put both areas together and then mature very quickly.
Almost every organization follows the same trajectory; however, some are able to progress more quickly while others become mired in the Pit of Despair.

Page 5 of 65
How to Create Application Security Design
Requirements

Organizations do spend on security, but they don’t necessarily spend in the right areas.
Organizations that spend time on testing and assessment before conducting training or making security design or architecture decisions can waste a lot of
time and money.

On Screen Text

Understanding the ASM Model

Page 6 of 65
How to Create Application Security Design
Requirements

Understanding_the_ASM Model_Continued

Narration
As we just pointed out, companies often invest in tools and technology before they invest in people and processes. After a security incident, they may rush
to invest in a typical set of security tools:
version control systems, source code scanning tools, defect management control systems, test automation systems, web application vulnerability scanning
and application-layer security mitigation (or firewalls).
However, these tools are only effective if appropriate investment is first made in people and processes, so that the tools are well-implemented and well-
utilized.
For example, source code scanning tools can improve security only if the tools are properly integrated into the development lifecycle, and personnel are
trained to correctly interpret results and implement fixes.
The people and process investments that are required are: secure SDLC activities for development teams,
staff training, the use of internal "Red Teams," third-party security reviews, application security audit procedures for all application types, and integration
with IRM, compliance, and governance initiatives.
When technology, people and processes are balanced, application security maturity is reached.

On Screen Text

Understanding the ASM Model - (Contd...)

Page 7 of 65
 How to Create Application Security Design
Requirements

• Version Control

• Source Code Scanning Tools

• Defect Management

• Test Automation

• Web Security Vulnerability Scanning

• Application-layer Security Mitigations, e.g., Web Application Firewall

• Secure SDLC Activities for Development Teams

• Staff Training (technical & awareness)

• Internal “Red Teams”

• 3rd Party Security Reviews (at code and as-built layers)

• Application Security audit procedures for ALL application types

• Integration with IRM, Compliance, and Governance initiatives

• Version Control

• Source Code Scanning Tools

• Defect Management

• Test Automation

• Web Security Vulnerability Scanning

• Application-layer Security Mitigations, e.g., Web Application Firewall

• Secure SDLC Activities for Development Teams

• Staff Training (technical & awareness)

• Internal “Red Teams”

• 3rd Party Security Reviews (at code and as-built layers)

• Application Security audit procedures for ALL application types

• Integration with IRM, Compliance, and Governance initiatives

Page 8 of 65
How to Create Application Security Design
Requirements

What_Is_Security_Engineering?

Narration
To keep its information secure, an organization must preserve the confidentiality, integrity, and availability of that information.
Confidentiality means that private data remains private. Integrity means that the data is correct and in the expected form. Availability means that the data
can be accessed when needed.
Software applications must be engineered to support and maintain these three properties when handling information.
Security engineering defines a set of security activities, processes, and policies that can be layered on top of your current development process. It can be
used in waterfall,
iterative, agile or any other process. The goal is to perform the correct activities and employ the right checkpoints at the appropriate points in your process.
A successful approach to security engineering involves explicit security objectives, a good understanding of the threats to your application,
and an iterative approach that allows you to consider security early and improve security over time instead of trying to add it all in at the end.

On Screen Text

What Is Security Engineering?

To keep its information secure, an organization must preserve the confidentiality, integrity, and availability of that information.
Software applications must be engineered to support and maintain these three properties when handling information.

Page 9 of 65
 How to Create Application Security Design
Requirements

Security engineering defines a set of security activities, processes, and policies that can be layered on top of your current
development process.

A successful approach to security engineering involves:

● Identifying your objectives

• Understanding the security objectives for your application early helps guide threat modeling, code design and development,
code reviews, and testing.

● Knowing your threats

• Analyzing your application in a structured and systematic way helps you discover its vulnerabilities and the threats that can
affect it.

● Using an iterative approach

• Some activities should be performed multiple times during the development process to maximize application security.

An improved secure development process results in more-secure code and reduced risk for your business and your customers.

Page 10 of 65
How to Create Application Security Design
Requirements

Adopting_a_Secure_Development_Life_Cycle_with_Security_Engineering

Narration
Security-engineering activities can be layered into any normal software development process. Whether you use waterfall or agile development
methodology,
you probably already perform many of the core development activities shown in this diagram. To add security engineering, you simply add security activities
at the appropriate times.
For instance, when you would normally determine your functional requirements, you would also determine your security objectives. When you would
normally apply design best practices,
you can perform threat modeling and apply security design best practices as well. You can perform security code review during the development phase,
and penetration testing when the application is ready for it. Finally, before you release the software, perform your security deployment review.
In addition to these specific activities, keep in mind that you should use the security best practices and guidelines through the design, development, and
deployment phases.
To implement security engineering in your development process, you do not need to change your existing process. You just need to augment it with a set of
high-impact security activities.

On Screen Text

To implement security engineering in your development process, you do not need to change your existing process. You just
need to augment it with a set of effective security activities.

Page 11 of 65
How to Create Application Security Design
Requirements

Adopting a Secure Development Life Cycle with Security Engineering

Planning

Requirements

and Analysis

and Design

Architecture

Development

Testing

Deployment

Maintenance

Core

Functional Requirements

Non Functional Requirements

Technology Requirements

Design Guidelines

Architecture and Design Review

Unit Tests

Code Review

Daily Builds

Integration Testing

System Testing

Deployment Review

Security

Security Objectives

Design Guidelines for Security

Threat Modeling

Arch and Design Review for Security

Code Review for Security

Security Testing

Page 12 of 65
How to Create Application Security Design
Requirements

Deployment Review for

Security

Page 13 of 65
How to Create Application Security Design
Requirements

Key_Security_Activities

Narration
Now that you understand how security-engineering activities fit into your development life cycle, let’s look at each activity in more detail.
Identify security objectives to understand your key security issues and scenarios.
Apply security design guidelines to avoid common security design mistakes and learn from past vulnerabilities.
Conduct security architecture and design reviews to identify security problems that can have a multiplier effect in later phases of development.
Create threat models to identify threats, attacks, vulnerabilities, and countermeasures.
Perform security code reviews and penetration tests to uncover vulnerabilities during development and in deployment.
Finally, conduct security deployment reviews to ensure that configuration and deployment problems are found before your application is placed into
production.

On Screen Text

Key Security Activities

Now that you understand how security-engineering activities fit into your development life cycle, let’s look at each activity in
more detail.

Page 14 of 65
 How to Create Application Security Design
Requirements

• Identify security objectives to understand your key security issues and scenarios.

• Apply security design guidelines to avoid common security design mistakes and learn from past vulnerabilities.

• Conduct security architecture and design reviews to identify security problems that can have a multiplier effect in later
phases of development.

• Create threat models to identify threats, attacks, vulnerabilities, and countermeasures.

• Perform security code reviews and penetration tests to uncover vulnerabilities during development and in deployment.

• Conduct security deployment reviews to ensure that configuration and deployment problems are found before your
application is placed into production.

Type the caption text here.

For more information, see the TEAM Mentor article Integrate Security Activities into the Development Lifecycle.

Page 15 of 65
How to Create Application Security Design
Requirements

Module_Summary

Narration
On Screen Text

Module Summary
1

Page 16 of 65
 How to Create Application Security Design
Requirements

Apply the ASM model to your development process.

The ASM model maps the security choices and decisions that organizations make and where it impacts them. Organizations
do spend on security, but they don’t necessarily spend in the right areas.

Most organizations follow a security path that has three distinct phases:
• Panic Scramble – In this phase, organizations realize that they have to do something about software security, so they invest
in tools and technology.
• Pit of Despair – Here, organizations realize that they don’t know how to use their expensive tools, they get discouraged,
and tool usage drops.
• Security as a Core Business Practice – In this phase, they start to understand not just the tools and technology but also
people and processes, and then mature very quickly.

Click here to review this topic again.

Describe the security-engineering process.

Security engineering defines a set of security activities, processes, and policies that can be layered on top of your current
development process.

To implement security engineering in your development, you don’t change your existing process; instead, you augment it
with effective security activities.
To implement security engineering successfully:

• Understand the security objectives for your application.

• Analyze your application in a structured and systematic way to recognize its threats and vulnerabilities.
• Perform key activities during the development process to maximize application security.

Click here to review this topic again.

Describe the key security-engineering activities that you can use to integrate security in your development life
cycle.

The six key security-engineering activities you perform to integrate security in your development life cycle are:
• Identify security objectives.
• Apply security design guidelines.
• Conduct security architecture and design reviews.
• Create threat models.
• Perform security code reviews and penetration tests.
• Conduct security deployment reviews.

Click here to review this topic again.

Page 17 of 65
How to Create Application Security Design
Requirements

Module_Overview_and_Objectives

Narration
According to the International Data Corporation, it is 15 times more expensive to fix a defect in the testing phase than in the design phase. If you are not
thinking about security in the design phase,
and if you are not driving your application design with security in mind, your application will be less secure in production and any security efforts you take
will be more expensive.
If you make the right design decisions with security in mind, it will have a cascading, positive impact on the rest of your development process.
Building security in from the start is the best way to create secure software with the lowest disruption to your development process.
After completing this module, you will be able to determine your security objectives, apply security design guidelines, and create threat models that identify
threats, attacks, vulnerabilities, and countermeasures.
You will also be able to conduct security architecture and design reviews that help identify potential security problems, and minimize your application’s
attack surface.

Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of application data,
software applications must be engineered with security in mind from inception through deployment. If you are not thinking about security in the design
phase,
and if you are not driving your application design with security in mind, your application will be less secure in production, and any security efforts you take at
that point will be more expensive.
Use security requirements to focus your design and development efforts on the most important objectives from a security perspective.

Page 18 of 65
 How to Create Application Security Design
Requirements

During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security impact.
This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best way to create secure software with
minimal disruption to your development process.
In this course, you will learn to integrate security engineering in your development life cycle.
You will also learn to define security requirements and objectives during the requirements phase of your application development.
Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of application data, software
applications must be engineered with security in mind from inception through deployment.
If you are not thinking about security in the design phase, and if you are not driving your application design with security in mind, your application will be
less secure in production, and any security efforts you take at that point will be more expensive.
Use security requirements to focus your design and development efforts on the most important objectives from a security perspective.
During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security impact.
This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best way to create secure software with
minimal disruption to your development process.
In this course, you will learn to integrate security engineering in your development life cycle. You will also learn to define security requirements and
objectives during the requirements phase of your application development.

On Screen Text

Module Overview and Objectives

Module Overview
According to the International Data Corporation, it is 15 times more expensive to fix a defect in the testing phase than in the
design phase. If you are not thinking about security in the design phase, and if you are not driving your application design
with security in mind, your application will be less secure in production and any security efforts you take will be more
expensive.

Module Objectives
After completing this module, you will be able to:

• Determine your security objectives.

• Apply security design guidelines.
• Create threat models that identify threats, attacks, vulnerabilities, and countermeasures.
• Conduct security architecture and design reviews that help identify potential security problems.
• Minimize your application’s attack surface.

If you make the right design decisions with security in mind, it will have a cascading, positive impact on the rest of your
development process. Building security in from the start is the best way to create secure software with the lowest disruption
to your development process.

Module Overview
According to the International Data Corporation, it is 15 times more expensive to fix a defect in the testing phase than in the
design phase. If you are not thinking about security in the design phase, and if you are not driving your application design
with security in mind, your application will be less secure in production and any security efforts you take will be more
expensive.

Module Overview
According to the International Data Corporation, it is 15 times more expensive to fix a defect in the testing phase than in the
design phase. If you are not thinking about security in the design phase, and if you are not driving your application design
with security in mind, your application will be less secure in production and any security efforts you take will be more
expensive.

Page 19 of 65
How to Create Application Security Design
Requirements

Page 20 of 65
 How to Create Application Security Design
Requirements

Know_Your_Security_Goals_and_Objectives

Narration
Define security objectives at the beginning of the development process to identify goals and constraints that affect the confidentiality, integrity, and
availability of your data and application.
Use your security goals to filter the set of applicable design guidelines, guide threat modeling, scope and guide architecture and design reviews, help set
code review objectives, guide security test planning and execution, and conduct deployment reviews.
If you don’t know what the security goals and objectives are for your application, it is difficult to be successful with any other security activity.

On Screen Text

Know your Security Goals and Objectives

Define security objectives at the beginning of the development process in order to identify goals and constraints that affect
the confidentiality, integrity, and availability of your data and application.

Use your security goals to:

• Filter the set of applicable design guidelines.

• Guide threat modeling.
• Scope and guide architecture and design reviews.

Page 21 of 65
 How to Create Application Security Design
Requirements

• Help set code review objectives.

• Guide security test planning and execution.
• Guide deployment reviews.

If you don’t know what the security goals and objectives are for your application, it is difficult to be successful with any other
security activity at any other phase of the development life cycle.

Page 22 of 65
How to Create Application Security Design
Requirements

The_Discovery_Process

Narration
Determining your security objectives is an iterative process driven by your application requirements, key assets, and usage scenarios.
You can begin identifying your objectives during the requirements phase, but the process will continue during threat modeling, design, and possibly
implementation.
As you move from initial security objectives to architectural and implementation decisions, you will make increasingly specific decisions regarding
application security.

On Screen Text

The Discovery Process

Identifying security objectives and goals is an iterative process.

This discovery process is initially driven by an examination of the application’s requirements and usage scenarios. By the
end of the requirements and analysis phase, you should have a first set of objectives that are not yet tied to design or
implementation details, such as “there will be data that is private”.

During the design phase, additional objectives will surface that are specific to the application architecture and design, such
as “passwords in the database must be hashed”.

Page 23 of 65
How to Create Application Security Design
Requirements

During the implementation phase, you may discover a few additional objectives based upon specific technology or
implementation choices that have an impact on overall application security, such as using a web framework to gain security
features.

Note: Each evolution of the security objectives will impact other security activities.

Identifying security objectives and goals is an iterative process.

This discovery process is initially driven by an examination of the application’s requirements and usage scenarios. By the
end of the requirements and analysis phase, you should have a first set of objectives that are not yet tied to design or
implementation details, such as “there will be data that is private”.

During the design phase, additional objectives will surface that are specific to the application architecture and design, such
as “passwords in the database must be hashed”.

During the implementation phase, you may discover a few additional objectives based upon specific technology or
implementation choices that have an impact on overall application security, such as using a web framework to gain security
features.

Note: Each evolution of the security objectives will impact other security activities.

For more information, see the TEAM Mentor article Identify Security Objectives.

Page 24 of 65
How to Create Application Security Design
Requirements

Questions_to_Ask

Narration
A question-driven approach can be an effective way to discover your security objectives.
Objectives will center on tangible or intangible assets you want to protect, compliance requirements, and quality-of-service requirements.
Click each objective category to view a list of questions for that category.

On Screen Text

Questions to Ask
A question-driven approach can be an effective way to discover your security objectives. Objectives will center on tangible or
intangible assets you want to protect, compliance requirements, and quality-of-service requirements.

Click each objective category to view a list of questions for that category.

210

Page 25 of 65
 How to Create Application Security Design
Requirements

Tangible Assets to Protect

• Are there user accounts and passwords to protect?

• Is there confidential user information (such as credit card numbers) that needs to be protected?
• Is there sensitive intellectual property that needs to be protected?
• Can this system be used as a conduit to access other corporate assets that need to be protected?

Intangible Assets to Protect

• Are there corporate values that could be compromised by an attack on this system?
• Is there potential for an attack that may be embarrassing, although not otherwise damaging?

Compliance Requirements

• Are there corporate security policies that must be adhered to?

• Is there security legislation you must comply with?
• Is there privacy legislation you must comply with?
• Are there standards you must adhere to?
• Are there constraints forced upon you by your deployment environment?

Quality of Service Requirements

• Are there specific availability requirements you must meet?

• Are there specific performance requirements you must meet?

Page 26 of 65
How to Create Application Security Design
Requirements

The_Matrix_Approach

Narration
You can use an access-control matrix to determine additional objectives. This matrix allows you to plot roles in your system and the permissions each role
should have on system assets.
From this matrix, you can use confidentiality, integrity, and availability (CIA) to derive security objectives.

On Screen Text

The Matrix Approach

You can use an access-control matrix to determine additional objectives. The matrix allows you to plot out roles in your
system and the permissions each role should have on system assets. From this matrix, you can use confidentiality, integrity,
and availability (CIA) to derive security objectives.

For more information, see the TEAM Mentor article Use Role-based Authorization.

Page 27 of 65
How to Create Application Security Design
Requirements

Security_Design_Guidelines

Narration
Security guidelines represent proven practices evolved over time to reduce risk. They describe the areas in which poor design can lead to security
vulnerabilities.
You can reduce risk by addressing common vulnerabilities, allowing you to focus on the unique aspects of your design.
Security design guidelines describe the areas in which poor design can lead to security vulnerabilities. Each guideline must be actionable, relevant, and
effective.

On Screen Text

Security Design Guidelines

Security guidelines represent proven practices evolved over time to reduce risk. They describe the areas in which poor
design can lead to security vulnerabilities. You can reduce risk by addressing common vulnerabilities, allowing you to focus
on the unique aspects of your design.

Each guideline must meet the qualifications as specified in the adjacent table.

Page 28 of 65
How to Create Application Security Design
Requirements

You can add additional guidelines or refine existing guidelines based on newly discovered vulnerabilities.

For more information, see the TEAM Mentor article Apply Security Design Guidelines.

Page 29 of 65
How to Create Application Security Design
Requirements

Potential_Problems_Due_to_Bad_Design

Narration
Security design guidelines are categorized in a security frame, which describes the areas where poor design can cause security vulnerabilities.
This example of a security frame categorizes common mistakes observed in a web application.
For each of these categories, you can identify examples of problems that can cause an attack.
Click each tab to learn more about the potential problems caused by bad design.

On Screen Text

Potential Problems Due to Bad Design

Security design guidelines are categorized in a security frame, which describes the areas where poor design can cause
security vulnerabilities. This example of a security frame categorizes common mistakes observed in a web application.

For each of these categories, you can identify examples of problems that can cause an attack.

Click each tab to learn more about the potential problems caused by bad design.

Page 30 of 65
How to Create Application Security Design
Requirements

10

Input/Data Validation

Insertion of malicious strings in UI or public APIs. These attacks include command execution, cross-site scripting (XSS),
SQL injection, and buffer overflows. Results can range from information disclosure to elevation of privilege and arbitrary
code execution.

Authentication

Identity spoofing, password cracking, elevation of privileges, and unauthorized access.

Authorization

Access to confidential or restricted data, data tampering, and execution of unauthorized operations.

Configuration Management

Unauthorized access to administration interfaces, ability to update configuration data, and unauthorized access to user
accounts and account profiles.

Sensitive Data

Confidential information disclosure and data tampering.

Cryptography

Access to confidential data or account credentials, or both.

Exception Management

Denial of service and disclosure of sensitive system-level details.

Auditing and Logging

Failure to spot the signs of intrusion, inability to prove a user's actions, and difficulties in problem diagnosis.

Page 31 of 65
How to Create Application Security Design
Requirements

Design_Guidelines_Best_Practices

Narration
Now that you are familiar with the common vulnerability categories and common problems in each category, let’s review design best practices that will help
you mitigate potential vulnerabilities.
Using the security frame for a web application as an example, these are a set of high-level guidelines to adhere to in the course of design. Keeping these
practices in mind will help you discover gaps in your design or areas where mistakes are being made.
Click each tab to learn more about the best practices.

On Screen Text

Design Guidelines – Best Practices

Now that you are familiar with the common vulnerability categories and the problems that can cause attacks, let’s review the
design best practices that will help you mitigate potential problems. We’ll again use the frame for a web application.

Click each tab to learn more about the best practices.

1
0

Page 32 of 65
How to Create Application Security Design
Requirements

Input/Data Validation

Do not trust input; consider centralized input validation. Do not rely on client-side validation. Be careful with canonicalization
issues. Constrain, reject, and sanitize input. Validate for type, length, format, and range.

Authentication

Use strong passwords. Support password expiration periods and account disablement. Do not store credentials (use one-
way hashes with salt). Encrypt communication channels to protect authentication tokens.

Authorization

Use least-privileged accounts. Consider authorization granularity. Enforce separation of privileges. Restrict user access to
system-level resources.

Configuration Management

Use least privileged process and service accounts. Do not store credentials in clear text. Use strong authentication and
authorization on administration interfaces. Secure the communication channel for remote administration.

Sensitive Data

Avoid storing secrets. Encrypt sensitive data over the wire. Secure the communication channel. Provide strong access
controls for sensitive data stores.

Cryptography

Do not develop your own. Use proven and tested platform features. Keep unencrypted data close to the algorithm. Use the
right algorithm and key size. Avoid key management (use DPAPI). Cycle your keys periodically.
Store keys in a restricted location.

Exception Management

Use structured exception handling. Do not reveal sensitive application implementation details. Do not log private data such
as passwords. Consider a centralized exception-management framework.

Auditing and Logging

Identify malicious behavior. Know what good traffic looks like. Audit and log activity through all of the application tiers.
Secure access to log files. Back up and regularly analyze log files.

Page 33 of 65
 How to Create Application Security Design
Requirements

What_is_Threat_Modeling?

Narration
Secure software starts with an understanding of the threats that pose a risk to your application.
It is important not to confuse threats with vulnerabilities. Remember that a threat is what an attacker might try to do to a protected resource in the system,
whereas, vulnerability is a specific way that a threat is exploitable based on an unmitigated attack path.
Threat modeling helps you create secure applications. It allows you to enumerate and understand key assets, risks, and potential design vulnerabilities that
exist in your application.
Revise your threat models periodically to account for new threats resulting from new and evolving attack techniques.

On Screen Text

What is Threat Modeling?

Secure software starts with an understanding of the threats that pose a risk to your application. It is important not to confuse
threats with vulnerabilities.

Remember that:
• A Threat is what an attacker might try to do to a protected resource in the system.
• A Vulnerability is a specific way that a threat is exploitable, based on an unmitigated attack path.

Page 34 of 65
How to Create Application Security Design
Requirements

Threat modeling helps you create secure applications. It allows you to enumerate and understand key assets, risks, and
potential design vulnerabilities that exist in your application.

Revise your threat models periodically to account for new threats resulting from new and evolving attack techniques.

Attacker

For more information, see the TEAM Mentor article Create a Threat Model for a Web Application at Design Time.

Mitigation

Threat

Vulnerability

Page 35 of 65
How to Create Application Security Design
Requirements

Benefits_of_Threat_Modeling

Narration
Threat modeling helps you understand application risk, shape your application design to meet your security objectives, identify where more resources are
required to reduce risks, and weigh security decisions against other design goals.
The ultimate goal of a threat model is to improve the security of your application by designing and implementing effective countermeasures to recognized
threats.
Since a threat model helps you understand attack vectors for and the conditions under which an attack may be successful, it is a very useful asset when
planning and conducting a penetration test.

On Screen Text

Benefits of Threat Modeling

In order to make the most impact, threat modeling should be performed in the architecture and design phase. You can start
threat modeling as soon as you understand your security objectives and have an application architecture in place.

You can use threat modeling to identify threats and vulnerabilities that are relevant for your application and determine
countermeasures to mitigate vulnerabilities.

Threat modeling also helps you update and improve iteratively when your security objectives change, when your design
changes, and during implementation, testing, and deployment.

Page 36 of 65
 How to Create Application Security Design
Requirements

In addition, you can use threat modeling to identify specific considerations such as:
• Legal requirements: SOX, GLBA, HIPAA, SB 1386, and more on the horizon
• Safety requirements
• Contractual requirements or customer needs

Page 37 of 65
How to Create Application Security Design
Requirements

Threat_Modeling_Activity_Overview

Narration
The five major threat modeling steps are shown in this diagram.
In step one, identify your security objectives. Clear objectives help you to focus the threat modeling activity and determine how much effort to spend on
subsequent steps.
In step two, create an application overview. Itemizing your application's important characteristics and actors helps you to identify relevant threats during
step four.
In step three, decompose your application. A detailed understanding of the mechanics of your application makes it easier for you to uncover more relevant
and more detailed threats.
In step four, identify threats. Use details from steps two and three to identify threats relevant to your application scenario and context.
In step five, identify vulnerabilities. Review the layers of your application to identify weaknesses related to your threats. Use vulnerability categories to help
you focus on those areas where mistakes are most often made.
You should progressively refine your threat model by repeatedly performing steps two through five. You can add more detail as you move through your
application development life
cycle and discover more about your application design.

On Screen Text

Threat Modeling – Activity Overview

Page 38 of 65
How to Create Application Security Design
Requirements

The five major threat modeling steps are shown in this diagram. You should progressively refine your threat model by
repeatedly performing steps two through five. You will be able to add more detail as you move through your application
development life cycle and discover more about your application design.

Page 39 of 65
How to Create Application Security Design
Requirements

Threat_Modeling_Activity_Summary_Table

Narration
Each step in the threat modeling process has specific inputs and outputs.
For example, when you are creating an application overview, you will use functional specifications, deployment diagrams, and use cases as input to create
a number of different outputs including an end-to-end deployment scenario,
key user and attack scenarios, the key roles in your system, the technologies involved, and the security mechanisms that are already in place.
The table shown here lists the inputs that you may need at each step of the threat modeling process and the outputs generated when you perform each
step.

On Screen Text

Threat Modeling – Activity Summary Table

Each step in a threat modeling exercise has specific inputs and outputs.

The table below lists the inputs that you may need at each step of the threat modeling process and the outputs that you
generate when you perform the step.

Page 40 of 65
 How to Create Application Security Design
Requirements

Mitigating_Your_Threats

Narration
One of the key goals of the threat model is to produce design-level mitigations for key threats.
When faced with a significant threat, you can choose to redesign your system in a way that eliminates the threat, you could use a mitigating technique to
reduce or eliminate the threat, or you can choose to accept the threat.
This attack tree example describes a number of ways that an attacker can impersonate an authorized user of your system.
Redesigning your system in a way that eliminates this threat is probably not an option; it would require a major modification to usage scenarios.
To diminish the threat, you can apply mitigations to each branch of the attack tree. For example, you can ensure server-side input and data validation to
keep an attacker from bypassing security checks on the client.
You can also encrypt credentials on the network and in memory to keep an attacker from stealing these credentials and reusing them.

On Screen Text

Mitigating Your Threats

Once you’ve identified the key threats to your application, you can decide how to handle each threat.

• Redesign and eliminate

• Use a mitigation technique

Page 41 of 65
 How to Create Application Security Design
Requirements

• Accept the risk in accordance with your organization’s risk tolerance

Threat_Modeling_Best_Practices

Narration
Here are some best practices that you should follow while performing threat modeling. First, enumerate assets of value.
Understand what assets matter to you as a business as well as what assets may matter to an attacker—for example, site login credentials.
Then, consider the threats. For each asset, consider the potential threats that could impact the asset. Consider the confidentiality, integrity, and availability
(CIA) for each asset.
For example, login credentials could be stolen or modified, or the login service could be denied to legitimate users.
You can brainstorm attacks. For each threat, consider what attacks could realize the threat—for example, network sniffing and man-in-the-middle.
Next, identify those conditions under which each attack could possibly succeed—for example, clear-text login credentials sent over a public network.

On Screen Text

Threat Modeling – Best Practices

Here are some best practices that you should follow while performing threat modeling.

Page 42 of 65
 How to Create Application Security Design
Requirements

Optimizing_Test_Efforts_by_Threat_Modeling

Narration
Threat profiles can serve as a basis for security test planning.
Now that you know your assets, threats, potential attacks, and the conditions under which an attack will be successful, you can use the threat profile to plan
your security testing.
The test plan should focus on the key attack conditions to prove or disprove threats to your system. This ensures that you are testing the areas where the
difficulty of attack is lowest and the impact is highest.

On Screen Text

Benefits of Threat Modeling

Threat profiles can serve as a basis for security test planning.

A threat profile includes:

• Assets of value
• Threats that could compromise those assets
• Attacks that could realize the threats
• Key conditions that must be met for each attack to be successful

The test plan should focus on testing the key attack conditions in order to prove or disprove threats to your system. This
ensures that you are testing the areas where the difficulty of attack is lowest and the impact is highest.

Page 43 of 65
How to Create Application Security Design
Requirements

Page 44 of 65
 How to Create Application Security Design
Requirements

Architecture_and_Design_Reviews

Narration
The goals of performing an architecture and design review are to analyze application architecture and design from a security perspective, and to expose
high-risk design decisions that have been made.
During design review, don’t rely solely on the use of design documentation. Use a combination of design documents, architecture experts, and discussion to
achieve the best results.

On Screen Text

Architecture and Design Reviews

The goals of performing an architecture and design review are to:
• Analyze application architecture and design from a security perspective.
• Expose high-risk design decisions that have been made.

During design review, don’t rely solely on the use of design documentation. Use a combination of design documents,
architecture experts, and discussion to achieve the best results.

For more information, see the TEAM Mentor article Conduct Security Architecture And Design Reviews.

Page 45 of 65
How to Create Application Security Design
Requirements

Applying_Vulnerability_Categories_and_Best_Practices

Narration
When performing architecture and design reviews, you should organize your reviews by common application vulnerability categories and look at the areas
in which mistakes are most often made and can have the most security impact.
For each vulnerability category, keep best practices in mind. Guidelines and best practices will help you discover gaps in your design or areas where
mistakes are being made. Don’t repeat the mistakes of the past.

On Screen Text

Applying Vulnerability Categories and Best Practices

When performing architecture and design reviews, you should organize your reviews by common application vulnerability
categories and look at the areas in which mistakes are most often made and where mistakes can have the most security
impact.

To view an example of common vulnerability categories observed in web applications, click here.

For each vulnerability category, keep best practices in mind. Guidelines and best practices will help you discover gaps in
your design or areas where mistakes are being made. Don’t repeat the mistakes of the past.

To view a set of best practices for web applications, click here.

Page 46 of 65
How to Create Application Security Design
Requirements

Architecture_and_Design_Review_Checklists

Narration
From these best practices, you can derive a set of checklists that make it much easier to review the design of your system.
Each vulnerability category should have its own set of potential problems that you can check against. These checklists represent areas where mistakes are
most often made.
A checklist driven approach will ensure consistent high-quality reviews over time and will give you confidence you are achieving a high degree of coverage.
As you perform your reviews,
the checklists can grow based on additional issues you find and knowledge you acquire along the way. You can also add checklist items that are unique to
your application and its security architecture.
Here is an example of an input and data validation checklist for a web application.

On Screen Text

Architecture and Design Review – Checklists

From these best practices, you can derive a set of checklists that make it much easier to review the design of your system.
Each vulnerability category should have its own set of potential problems that you can check against. These checklists
represent areas where mistakes are most often made

Page 47 of 65
 How to Create Application Security Design
Requirements

A checklist driven approach will ensure consistent high-quality reviews over time and will give you confidence you are
achieving a high degree of coverage. As you perform your reviews, the checklists can grow based on additional issues you
find and knowledge you pick up along the way. You can also add checklist items that are unique to your application and its
security architecture.

❑ All entry points and trust boundaries are identified by the design.

❑ Input validation is applied whenever input is received from outside the current trust boundary.

❑ The design assumes that user input is malicious.

❑ Centralized input validation is used where appropriate.

❑ The input validation strategy that the application adopted is modular and consistent.

❑ The validation approach is to constrain, reject, and then sanitize input. (Looking for known, valid, and safe input is much easier than
looking for known malicious or dangerous input.)

❑ Data is validated for type, length, format, and range.

❑ The design addresses potential canonicalization issues.

❑ Input file names and file paths are avoided where possible.

❑ The design addresses potential SQL injection issues.

❑ The design addresses potential cross-site scripting issues.

❑ The design does not rely on client-side validation.

❑ The design applies defense in depth to the input validation strategy by providing input validation across tiers.

Type the caption text here.

Type the caption text here.

❑ All entry points and trust boundaries are identified by the design.

❑ Input validation is applied whenever input is received from outside the current trust boundary.

❑ The design assumes that user input is malicious.

❑ Centralized input validation is used where appropriate.

❑ The input validation strategy that the application adopted is modular and consistent.

❑ The validation approach is to constrain, reject, and then sanitize input. (Looking for known, valid, and safe input is much easier than
looking for known malicious or dangerous input.)

❑ Data is validated for type, length, format, and range.

❑ The design addresses potential canonicalization issues.

❑ Input file names and file paths are avoided where possible.

❑ The design addresses potential SQL injection issues.

❑ The design addresses potential cross-site scripting issues.

Page 48 of 65
 How to Create Application Security Design
Requirements

❑ The design does not rely on client-side validation.

❑ The design applies defense in depth to the input validation strategy by providing input validation across tiers.

Page 49 of 65
How to Create Application Security Design
Requirements

Architecture_and_Design_Review_Techniques

Narration
A question-driven approach helps you expose the highest-risk design decisions, and the security frame helps you focus on the areas that reveal common
mistakes.
To conduct an architecture and design review, create a list of questions about the security of each of the following three application components.
First, review the design of your application in relation to the target deployment environment and the associated security policies..
Next, review the critical areas in your application, such as authentication, authorization, input/data validation, exception management, and other areas.
Finally, walk through the logical tiers of your application, and evaluate security choices within your presentation, business, and data access layers

On Screen Text

Architecture and Design Review – Techniques

A question-driven approach helps you expose the highest-risk design decisions, and the security frame helps you focus on
the areas that reveal common mistakes.

To conduct an architecture and design review, create a list of questions about the security of each of the following three
application components.

Application

Page 50 of 65
How to Create Application Security Design
Requirements

Deployment and

Layer-By-Layer

Security Frame

Host

Network

Presentation

Business

Data

Input Validation

Session Management

Authentication

Cryptography

Configuration Mgmt

Exception Management

Sensitive Data

Auditing and Logging

Authorization

Parameter Manipulation

Infrastructure

Review the design of your application in relation to the target deployment environment and the associated security policies.

Deployment and
Infrastructure

x
Walk through the logical tiers of your application, and evaluate security choices within your presentation, business, and data
access layers.

Layer-By-Layer
Analysis

x
Review the critical areas in your application, such as authentication, authorization, input/data validation, exception
management, and other areas.

Security Frame

Page 51 of 65
How to Create Application Security Design
Requirements

Page 52 of 65
How to Create Application Security Design
Requirements

What_Is_Your_Application's_Attack_Surface

Narration
Your system’s attack surface represents the number of entry points you expose to a potential attacker. The fewer entry points, the less chance of an
attacker finding a vulnerability in your code.
No matter how hard you work to improve the security of your software, vulnerabilities, both known and unknown,
will still exist in your system. Attack surface reduction is an exercise in risk reduction, as you lower your attack surface you reduce the risk of a high impact
exploit in your system.
Consider two examples. First, imagine you are in charge of securing Notepad. The attack surface is small, a remote attacker can do very little to impact
your users.
Even if vulnerabilities exist in your code, chances are very small that you will be exploited.
Now, imagine that you are in charge of securing Internet Explorer. The attack surface is huge and a remote attacker can attack in numerous ways to impact
your users.
Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of application data,
software applications must be engineered with security in mind from inception through deployment. If you are not thinking about security in the design
phase,
and if you are not driving your application design with security in mind, your application will be less secure in production, and any security efforts you take at
that point will be more expensive.
Use security requirements to focus your design and development efforts on the most important objectives from a security perspective.
During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security impact.

Page 53 of 65
 How to Create Application Security Design
Requirements

This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best way to create secure software with
minimal disruption to your development process.
In this course, you will learn to integrate security engineering in your development life cycle.
You will also learn to define security requirements and objectives during the requirements phase of your application development.
Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of application data, software
applications must be engineered with security in mind from inception through deployment.
If you are not thinking about security in the design phase, and if you are not driving your application design with security in mind, your application will be
less secure in production, and any security efforts you take at that point will be more expensive.
Use security requirements to focus your design and development efforts on the most important objectives from a security perspective.
During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security impact.
This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best way to create secure software with
minimal disruption to your development process.
In this course, you will learn to integrate security engineering in your development life cycle. You will also learn to define security requirements and
objectives during the requirements phase of your application development.

On Screen Text

What is your Application's Attack Surface

Software exposes key business and customer assets through a number of entry points, such as:

• User interfaces
• Web services
• Direct database access
• Network channels
• Pipes
• Files
• APIs

The entire collection of entry points in a product is called its attack surface. This attack surface defines the ways in which
malicious users can attack a software system. The attack surface is not limited to local resources. For example, the channels
used to communicate with remote resources provide additional vectors for attack.

When considering application security, remember the following correlation:

Big Attack Surface = Big Security Work = Big Security Problems

When an application has a big attack surface, you have to spend more time to ensure that the code is conservative,
defensive, and of excellent quality.

Page 54 of 65
How to Create Application Security Design
Requirements

Attack_Surface_and_Entry_Points

Narration
When you consider how to reduce your attack surface, keep in mind that your attack surface is tightly linked to the entry points your application exposes.
Each entry point represents an avenue of attack you need to guard, multiplying the possibility of an exploit.
Attackers are guaranteed to go after your entry points first when looking for an exploit. The standard attack strategy is to identify entry points and then
leverage exploit code against each entry point in turn.
Attackers will try to exploit your application or reach backend components that are exposed behind your application. If none of this works, attackers may
attempt denial of service attacks that prevent legitimate users from accessing your system.
To reduce your risk, you need to reduce the number of entry points and then test what’s left for exposed vulnerabilities.
By doing this, you not only make the attacker’s job more difficult, you also make your testing job easier.
When measuring your attack surface, you can start with architecture documents, deployment diagrams, and other specifications. However,
keep in mind that the most dangerous aspects of your attack surface may be the functionality that is undocumented and not widely known.
To find these hidden entry points, you may need to examine code and run diagnostic tools on your application to determine all of the entry points your
application is exposing.
Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of application data,
software applications must be engineered with security in mind from inception through deployment. If you are not thinking about security in the design
phase,
and if you are not driving your application design with security in mind, your application will be less secure in production, and any security efforts you take at
that point will be more expensive.

Page 55 of 65
 How to Create Application Security Design
Requirements

Use security requirements to focus your design and development efforts on the most important objectives from a security perspective.
During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security impact.
This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best way to create secure software with
minimal disruption to your development process.
In this course, you will learn to integrate security engineering in your development life cycle.
You will also learn to define security requirements and objectives during the requirements phase of your application development.
Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of application data, software
applications must be engineered with security in mind from inception through deployment.
If you are not thinking about security in the design phase, and if you are not driving your application design with security in mind, your application will be
less secure in production, and any security efforts you take at that point will be more expensive.
Use security requirements to focus your design and development efforts on the most important objectives from a security perspective.
During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security impact.
This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best way to create secure software with
minimal disruption to your development process.
In this course, you will learn to integrate security engineering in your development life cycle. You will also learn to define security requirements and
objectives during the requirements phase of your application development.

On Screen Text

Attack Surface and Entry Points

To attack an application, malicious users will:

• Identify entry points

• Exploit the entry point or the backend exposed behind it
• Try to deny legitimate users the access to these entry points

Therefore, in your software, you need to understand the attack surface and reduce it as much as possible. You’ll need to test
against the attack surface to identify exposed vulnerabilities.

You should map your attack surface with architecture and design documents, with code reviews, and by using diagnostic
tools. You should also identify the undocumented entry points such as temporary files, pipes, network communication,
registry keys, and embeddable code.

Page 56 of 65
How to Create Application Security Design
Requirements

The_Attack_Surface_Reduction_Process

Narration
So, how do you reduce the attack surface? Begin by identifying and understanding all of the entry points that make up the attack surface.
You can do this by enumerating all of the interfaces, protocols, and code execution paths as well as understanding the trust levels required to access each
entry point.
For each entry point, you must consider the importance of the feature that it enables. For features that are not important to a vast majority of the users, turn
the feature off, disable it by default, or don’t install it by default;
make your users take explicit action to enable that feature. Any vulnerabilities related to that feature will affect a smaller percentage of your user base.
Next, consider which types of users need access to each feature, and then restrict its use to those classes. For example,
don’t make the feature remotely accessible by default, allow anonymous access, or have it run with more privilege than required.
You can also reduce the attack surface by restricting access to a product feature and managing how users can obtain and use that access.
Without a conscious focus on this aspect of your software design and implementation, you are guaranteed to have a larger attack surface than necessary
and, as a result, a higher risk of an attacker exploiting your system.

On Screen Text

The Attack Surface Reduction Process

To reduce application attack surface, you begin by examining all of the entry points, such as network I/O and file I/O. You
can rank the entry points in the following manner:

Page 57 of 65
 How to Create Application Security Design
Requirements

• Authenticated versus anonymous

• Administrator only versus user
• Network versus local

Remember that attack surface reduction is as important as writing the code correctly.

Access Denied

Page 58 of 65
How to Create Application Security Design
Requirements

It's_Not_Just_About_Turning_Stuff_Off

Narration
Keep in mind that reducing attack surface is not as simple as flipping a binary switch. You need to manage how your software exposes its features and
reduce access to the minimum required to meet your specifications and usage scenarios.

You need to manage how your software exposes its features and reduce access to the minimum required to meet your specifications and usage scenarios.

On Screen Text

It's Not Just About Turning Stuff Off

Now, let’s look at some tips for reducing attack surface.

Keep in mind that reducing attack surface is not as simple as flipping a binary switch. You need to manage how your
software exposes its features and reduce access to the minimum required to meet your specifications and usage scenarios.

Page 59 of 65
How to Create Application Security Design
Requirements

Reducing_Your_Attack_Surface_Best_Practices

Narration
Define and reduce the attack surface early in your development cycle. When designing your application,
you can include a section in the design outlining what the attack surface will look like and then use that as foundation for future attack surface measurement
and reduction efforts.
You can reduce the amount of code that is included in your application or runs by default. An exploit that runs in deprecated code can be just as dangerous
as one that runs in commonly used code paths.
If you don’t need the code, remove it. Each line of code adds additional risk.
Reduce the number of access points accessible to untrusted users. Once you’ve cataloged your entry points, determine which of them need to be accessed
by untrusted users.
For example, you can restrict access to network endpoints used by your application to the local subnet or IP range. You can also limit access to network
endpoints by using authentication.
Reduce privileges to limit damage potential. For example, if your code doesn’t need access to system resources, remove the privilege.
By reducing the privileges of your running code, you are reducing the potential impact if an attacker finds a vulnerability.
You can raise the authorization bar on anonymous code paths in order to limit the number of users that can access potentially risky code paths.
Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of application data,
software applications must be engineered with security in mind from inception through deployment. If you are not thinking about security in the design
phase,

Page 60 of 65
 How to Create Application Security Design
Requirements

and if you are not driving your application design with security in mind, your application will be less secure in production, and any security efforts you take at
that point will be more expensive.
Use security requirements to focus your design and development efforts on the most important objectives from a security perspective.
During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security impact.
This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best way to create secure software with
minimal disruption to your development process.
In this course, you will learn to integrate security engineering in your development life cycle.
You will also learn to define security requirements and objectives during the requirements phase of your application development.
Security is an important component of an application’s quality. To preserve the confidentiality, integrity, and availability of application data, software
applications must be engineered with security in mind from inception through deployment.
If you are not thinking about security in the design phase, and if you are not driving your application design with security in mind, your application will be
less secure in production, and any security efforts you take at that point will be more expensive.
Use security requirements to focus your design and development efforts on the most important objectives from a security perspective.
During design reviews, keep design best practices in mind and look at the areas where mistakes can have the most security impact.
This will help you identify gaps in your design and mitigate potential risk. Building security in from the start is the best way to create secure software with
minimal disruption to your development process.
In this course, you will learn to integrate security engineering in your development life cycle. You will also learn to define security requirements and
objectives during the requirements phase of your application development.

On Screen Text

Reducing Your Attack Surface – Best Practices

Define and reduce the attack surface early in your development cycle. When designing your application, you can include a
section in the design outlining what the attack surface will look like and then use that as foundation for future attack surface
measurement and reduction efforts.

You can use the following key techniques to reduce your attack surface:

● Reduce the amount of running code.

● Reduce access to entry points by untrusted users.

• Restrict access to network endpoints used by your application to the local subnet or IP range.
• Limit access to network endpoints by using authentication.

● Reduce privileges to limit damage potential.

● Raise the authorization bar on anonymous code paths.

Page 61 of 65
How to Create Application Security Design
Requirements

Module Summary

Narration
On Screen Text

Module Summary
1

Page 62 of 65
 How to Create Application Security Design
Requirements

Determine your security objectives.

You define security objectives at the beginning of the development process to identify goals and constraints that affect the
confidentiality, integrity, and availability of your data and application. You can begin identifying your objectives during the
requirements phase, but the process continues during threat modeling, design, and possibly implementation.

A question-driven approach can be an effective way to determine your objectives. Objectives will center on tangible or
intangible assets you want to protect, compliance requirements, and quality-of-service requirements. You can also use a
subject-object matrix to determine additional objectives.

Click here to review this topic again.

Apply security design guidelines.

Security design guidelines describe the areas in which poor design can lead to security vulnerabilities. Each guideline must
be actionable, relevant, and impactful.

Security design guidelines are categorized in a security frame, which describes the areas where poor design can cause
security vulnerabilities. For each of these categories, you can identify examples of problems that can cause an attack.

Click here to review this topic again.

Create threat models that identify threats, attacks, vulnerabilities, and countermeasures.

Threat modeling helps you understand application risk, shape your application design to meet your security objectives,
identify where more resources are required to reduce risks, and weigh security decisions against other design goals.

Threat modeling includes five steps:

• Step 1: Identify security objectives.

• Step 2: Create an application overview
• Step 3: Decompose your application
• Step 4: Identify threats
• Step 5: Identify vulnerabilities

Progressively refine your threat model by performing steps 2 through 5 repeatedly. Each step in a threat modeling exercise
has specific inputs and outputs. Once you’ve identified the key threats to your application, you can decide how to handle
each threat.

Click here to review this topic again.

Conduct security architecture and design reviews that help identify potential security problems.

An architecture and design review help you analyze application architecture and design from a security perspective and
expose high-risk design decisions. When performing architecture and design reviews, organize your reviews by common
application vulnerability categories, and for each vulnerability category, keep best practices in mind. From the best practices,
you can derive a set of checklists that make it much easier to review the design of your system.

Page 63 of 65
 How to Create Application Security Design
Requirements

Use a three-pronged approach to conduct an architecture and design review:

• Deployment and infrastructure
• Security frame
• Layer-by-layer analysis

Click here to review this topic again

Minimize your application’s attack surface.

Your system’s attack surface represents the number of entry points you expose to a potential attacker. To reduce your attack
surface, you reduce the entry points and then test those points for exposed vulnerabilities. You can do this by enumerating
all of the interfaces, protocols, and code execution paths as well as understanding the trust levels required to access each
entry point.

Keep in mind that reducing attack surface is not as simple as flipping a binary switch. You need to manage how your
software exposes its features and reduce access to the minimum required to meet your specifications and usage scenarios.
You should define and reduce the attack surface early in your development cycle.

Click here to review this topic again.

Page 64 of 65
How to Create Application Security Design
Requirements

TEAM_Mentor_eKnowledge

Narration
On Screen Text

TEAM Mentor eKnowledge

Provides faster and better remediation guidance within the developer’s environment.

TEAM Mentor is an interactive Application Security eKnowledge base with thousands of articles on how to prevent
vulnerabilities during application development. Use TEAM Mentor to find guidance for implementing the application security
controls that are relevant to your particular application in your development language. With optional plugins to the most
popular Static and Dynamic code analysis tools, TEAM Mentor provides users with quick and easy access to comprehensive
security guidance that is accurate and relevant to specific code security questions. Integrating security scanning and
guidance into a development workflow ultimately results in quicker production of more secure and stable applications.

Page 65 of 65