CHAPTER 9 Design Considerations In this chapter you will

CHAPTER 9
Design Considerations
In this chapter you will
• Examine how to design security into an application using
core security concepts
• Learn the roles of confidentiality, integrity, and availability
with respect to
designing in information security principles
• Explore designing in security elements using authentication,
authorization, and
auditing
• Explore how to use secure design principles to improve
application security
• Learn how interconnectivity provides opportunities to design
in security
elements
Designing an application is the beginning of implementing
security into the final
application. Using the information uncovered in the
requirements phase,
designers create the blueprint developers use to arrive at the
final product. It is
during this phase that the foundational elements to build the
proper security
functionality into the application are initiated. To determine

which security
elements are needed in the application, designers can use the
information from
the attack surface analysis and the threat model to determine the
“what” and
“where” elements. Knowledge of secure design principles can
provide the “how”
elements. Using this information in a comprehensive plan can
provide developers
with a targeted foundation that will greatly assist in creating a
secure application.
Application of Methods to Address Core Security Concepts
In Chapter 1, we explored the basic principles of security. In
this chapter, we will
examine how to design in security by utilizing these concepts.
The concepts of
confidentiality, integrity, and availability, widely lauded as the
key elements of
information security, do not happen by accident—they must be
designed into the
application to be effective and to provide specific protections.
Confidentiality, Integrity, and Availability
The principles of confidentiality, integrity, and availability are
commonly used in
information security discussions. For these elements to be
effective in an
application, they need to be designed into the application during
the design
phase. This is done by using tools such as encryption, hashing,
and recovery

methods. Encryption can preserve confidentiality by making
information
unavailable to unauthorized parties. Integrity can be ensured
through the use of
hash codes. Designing in proper recovery methods provides for
a more resilient
application that can support higher availability.
Confidentiality
Confidentiality is the concept of preventing the disclosure of
information to
unauthorized parties. Keeping secrets secret is the core concept
of confidentiality.
One of the key elements in the design phase is determining what
elements need
to be kept secret. The threat model will identify those elements.
The next aspect is
to examine the state of the data that is to be kept confidential. If
the data is at rest,
then encryption can be used to restrict access to authorized
users. If the data is in
transit, then encryption can also be used, but the method of
encryption may be
based on the transport method. Data that needs to be kept
confidential in use, i.e.,
encryption keys, will require special attention.
Once the elements are determined, the next part of the
confidentiality
equation is to determine who the authorized parties are. The
concepts of
authorization are covered later in this chapter.
Integrity

Integrity refers to protecting data from unauthorized alteration.
Alterations can
come in the form of changing a value or deleting a value.
Integrity builds upon
confidentiality, for if data is to be altered or deleted, then it is
probably also
https://learning.oreilly.com/library/view/csslp-certification-all-
in-one/9781260441697/ch1.xhtml#ch1
visible to the user account. Users can be authorized to view
information, but not
alter it, so integrity controls require an authorization scheme
that controls
update and delete operations.
Protecting integrity can be done through the use of access
control mechanisms.
Individual specific levels of access with respect to read, write,
and delete can be
defined. Applying controls is just a piece of the integrity
puzzle. The other aspect
involves determining whether data has been altered or not. In
some cases, this is
just as important, if not more so, as the access control part. To
determine whether
the information has been altered or not requires some form of
control other than
simple access control.
If there is a requirement to verify the integrity of a data element
throughout its
lifecycle, the cryptographic function of hashing can be used.
Hash functions can
determine if single or multiple bits of data change from the

original form. The
principle is simple: Take the original data, run it through a hash
function, and
record the result. At any subsequent time, running the current
value of the data
through the same hash function will produce a current digest
value. If the two
digest values match, then the data is unchanged. This can be for
something small,
such as a few bytes, to an entire file system—in all cases, the
digest size is fixed
based on the hash algorithm.
The design issue is, how does one implement this functionality?
When are hash
digests calculated? How are the digests stored and transmitted
by a separate
channel to the party checking? Adding the necessary elements
to allow hash-
based checking of integrity requires the designing of the
necessary apparatus for
parties to be able to verify integrity. In some cases, like in
Microsoft Update
Service, this entire mechanism is designed into the transfer
mechanism so that it
is invisible to the end user. The design phase is where these
decisions need to be
made so that the coding phase can properly implement the
desired behavior.
Availability
Availability is defined as a system being available to authorized
users when
appropriate. Numerous threats can affect the availability of a
system. The threat

model should provide significant information as to what aspects
of a system need
availability protected and what aspects are not sensitive.
Designing the best
defenses against availability issues depends upon the threat to
availability.
Backups can provide a form of protection, as can data
replication. Failover to
redundant systems can also be employed. The key is in
determining the specifics
of the availability need and expressing them in a requirement
that is then
designed into the system.
Authentication, Authorization, and Auditing
The functions of authentication and authorization are
foundational elements of
employing controls such as access control lists. Designing these
elements into an
application is one where decisions need to be made as to
integration with
existing—i.e., operating system–provided functionality—or
designing and
building a stand-alone system. Auditing or logging is another
system
functionality, essential to security, where a design decision is
needed as to the
level of integration with existing operating system
functionality. In both of these
situations, it might seem easier to build your own system, but
the true
functionality needed in most system environments comes from

integration into
the larger enterprise-level security system, and this means
integration of
authentication, authorization, and auditing functionality into the
existing
operating system functionality.
Authentication
Authentication is the process used to verify to the computer
system or network
that the individual is who they claim to be. It is a key element
in the security of a
system, for if this system is bypassed or spoofed, then all
subsequent security
decisions can be in error. One of the key design questions is the
level of assurance
needed with respect to authentication. If an application is web-
based, where
users need to log in to establish their identity, then the design
and securing of this
information becomes an important part of the security equation.
Authentication
data is highly valuable data to an attacker and needs to be
protected. This shows
the interconnected nature of security, authentication, and
confidentiality issues,
as well as many others.
Authentication systems are complex, and the difficulty in
designing and
implementing them can be a daunting task. Whenever possible,
it is best to leave
authentication to established systems, such as the operating
system. This makes it
easier to integrate with existing operational security systems,

and most operating
system (OS) authentication systems are well tested and vetted.
If the OS method is
not appropriate, such as in web app login systems, then
adherence to proper
security design patterns for authentication systems is essential.
Authorization
After the authentication system identifies a user to a system, the
authorization
system takes over and applies the predetermined access levels to
the user. As
with authentication, authorization systems can be complex and
difficult to
implement correctly. For elements that can be covered by the
operating system
authorization system, i.e., access control lists for critical files
and resources, these
built-in and integrated systems should be utilized. If custom
authorization
elements are needed, they must be carefully designed using
proper security
design patterns for authorization systems.
Accounting (Audit)
Accounting is the function of measuring specific IT activities.
This is typically
done through the logging of crucial data elements of an activity
as it occurs. The
key elements in the design phase are the determination of what
crucial elements
should be logged and under what circumstances. Several sources

of information
can be used for determining what to log and when. The simplest
rule is to include
error trapping in every module and log what developers would
need to
understand the source of the problem. Caution should be
exercised in the logging
of data associated with records in the system. Data records
could contain
sensitive information that should be protected and not exposed
in logs. Should
sensitive data need to be logged, then encryption of the data is
needed to protect
the confidentiality requirements.
NOTE When logging information associated with a failure or
error, care must
be taken to not disclose any sensitive information in logs. This
includes elements
such as personally identifiable information (PII) and
programmatic elements
such as paths and filenames.
Secure Design Principles
Implementing secure design principles requires specific design
elements to be
employed. Using the information from the attack surface
analysis and the threat
model, designers can pinpoint the places where specific design
elements can be
employed to achieve the desired security objectives. Security
controls can be

chosen based on the design to implement the desired levels of
protection per
security requirements. This can include controls to ensure
confidentiality,
integrity, and availability.
The following are secure design principles that are employed to
achieve
application security:
Good Enough Security
When designing in security aspects of an application, care
should be exercised to
ensure that the security elements are in response to the actual
risk associated
with the potential vulnerability. Designing excess security
elements is a waste of
resources. Underprotecting the application increases the risk.
The challenge is in
determining the correct level of security functionality. Elements
of the threat
model and attack surface analysis can provide guidance as to
the level of risk.
Documenting the level and purpose of security functions will
assist the
development team in creating an appropriate and desired level
of security.
Least Privilege
One of the most fundamental approaches to security is least
privilege. Least

privilege should be utilized whenever possible as a preventative
measure.
Embracing designs with least privilege creates a natural set of
defenses should
unexpected errors happen. Least privilege, by definition, is
sufficient privilege,
and this should be a design standard. Excess privilege
represents potentially
excess risk when vulnerabilities are exploited.
Separation of Duties
Separation of duties must be designed into a system. Software
components can be
designed to enforce separation of duties when they require
multiple conditions to
be met before a task is considered complete. These multiple
conditions can then
be managed separately to enforce the checks and balances
required by the
system. In designing the system, designers also impact the
method of operation of
the system.
As with all other design choices, the details are recorded as part
of the threat
model. This acts as the communication method between all
members of the
development effort. Designing in operational elements such as
separation of
duties still requires additional work to happen through the
development process,
and the threat model can communicate the expectations of later

development
activities in this regard.
Defense in Depth
Defense in depth is one of the oldest security principles. If one
defense is good,
multiple overlapping defenses are better. The threat model
document will
contain information where overlapping defenses should be
implemented.
Designing in layers as part of the security architecture can work
to mitigate a
wider range of threats in a more efficient manner.
NOTE It’s not that I’m assuming your code will fail. It’s that
I’m assuming all code
can fail, including mine. You are not a special case. – Dan
Kaminsky, security guru
Because every piece of software can be compromised or
bypassed in some
way, it is incumbent on the design team to recognize this and
create defenses that
can mitigate specific threats. Although all software, including
the mitigating
defenses, can fail, the end result is to raise the difficulty level
and limit the risk
associated with individual failures.
Designing a series of layered defense elements across an
application provides
for an efficient defense. For layers to be effective, they should

be dissimilar in
nature so that if an adversary makes it past one layer, a separate
layer may still
be effective in maintaining the system in a secure state. An
example is the
coupling of encryption and access control methods to provide
multiple layers that
are diverse in their protection nature and yet both can provide
confidentiality.
Fail Safe
As mentioned in the exception management section, all systems
will experience
failures. The fail-safe design principle refers to the fact that
when a system
experiences a failure, it should fail to a safe state. When
designing elements of an
application, one should consider what happens when a particular
element fails.
When a system enters a failure state, the attributes associated
with security,
confidentiality, integrity, and availability need to be
appropriately maintained.
Failure is something that every system will experience. One of
the design
elements that should be considered is how the individual
failures affect overall
operations. Ensuring that the design includes elements to
degrade gracefully and
return to normal operation through the shortest path assists in
maintaining the
resilience of the system. For example, if a system cannot
complete a connection to
a database, when the attempt times out, how does the system

react? Does it
automatically retry, and if so, is there a mechanism to prevent a
lockup when the
failure continually repeats?
Economy of Mechanism
The terms security and complexity are often at odds with each
other. This is
because the more complex something is, the harder it is to
understand, and you
cannot truly secure something if you do not understand it.
During the design
phase of the project, it is important to emphasize simplicity.
Smaller and simpler
is easier to secure. Designs that are easy to understand, easy to
implement, and
well documented will lead to more secure applications.
If an application is going to do a specific type of function—for
example, gather
standard information from a database—and this function repeats
throughout the
system, then designing a standard method and reusing it
improves system
stability. As systems tend to grow and evolve over time, it is
important to design
in extensibility. Applications should be designed to be simple to
troubleshoot,
simple to expand, simple to use, and simple to administer.
Complete Mediation
Systems should be designed so that if the authorization system

is ever
circumvented, the damage is limited to immediate requests.
Whenever sensitive
operations are to be performed, it is important to perform
authorization checks.
Assuming that permissions are appropriate is just that—an
assumption—and
failures can occur. For instance, if a routine is to permit
managers to change a
key value in a database, then assuming that the party calling the
routine is a
manager can result in failures. Verifying that the party has the
requisite
authorization as part of the function is an example of complete
mediation.
Designing this level of security into a system should be a
standard design practice
for all applications.
Open Design
Part of the software development process includes multiple
parties doing
different tasks that in the end create a functioning piece of
software. Over time,
the software will be updated and improved, which is another
round of the
development process. For all of this work to be properly
coordinated, open
communication needs to occur. Having designs that are open
and understandable
will prevent activities later in the development process that will
weaken or
bypass security efforts.
Least Common Mechanism

The concept of least common mechanism is constructed to
prevent inadvertent
security failures. Designing a system where multiple processes
share a common
mechanism can lead to a potential information pathway between
users or
processes. The concepts of least common mechanism and
leverage existing
components can place a designer at a conflicting crossroad. One
concept
advocates reuse and the other separation. The choice is a case of
determining the
correct balance associated with the risk from each.
Take a system where users can access or modify database
records based on
their user credentials. Having a single interface that handles all
requests can lead
to inadvertent weaknesses. If reading is considered one level of
security and
modification of records a more privileged activity, then
combining them into a
single routine exposes the high-privilege action to a potential
low-privilege
account. Thus, separating mechanisms based on security levels
can be an
important design tool.
Psychological Acceptability
Users are a key part of a system and its security. To include a
user in the security
of a system requires that the security aspects be designed so

that they are
psychologically acceptable to the user. When a user is presented
with a security
system that appears to obstruct the user, the result will be the
user working
around these security aspects. Applications communicate with
users all the time.
Care and effort are given to ensuring that an application is
useable in normal
operation. This same idea of usability needs to be extended to
security functions.
Designers should understand how the application will be used in
the enterprise
and what users will expect of it.
When users are presented with cryptic messages, such as the
ubiquitous
“Contact your system administrator” error message, expecting
them to do
anything that will help resolve an issue is unrealistic. Just as
care and
consideration are taken to ensure normal operations are
comprehensible to the
user, so, too, should a similar effort be taken for abnormal
circumstances.
Weakest Link
Every system, by definition, has a “weakest” link. Adversaries
do not seek out the
strongest defense to attempt a breach; they seek out any
weakness they can
exploit. Overall, a system can only be considered as strong as
its weakest link.
When designing an application, it is important to consider both
the local and

system views with respect to weaknesses. Designing a system
using the security
tenets described in this section will go a long way in preventing
local failures
from becoming system failures. This limits the effect of the
weakest link to local
effects.
Leverage Existing Components
Modern software development includes extensive reuse of
components. From
component libraries to common functions across multiple
components, there is
significant opportunity to reduce development costs through
reuse. This can also
simplify a system through the reuse of known elements. The
downside of massive
reuse is associated with a monoculture environment, which is
where a failure
has a larger footprint because of all the places where it is
involved.
During the design phase, decisions should be made as to the
appropriate level
of reuse. For some complex functions, such as in cryptography,
reuse is the
preferred path. In other cases, where the lineage of a component
cannot be
established, then the risk of use may outweigh the benefit. In
addition, the
inclusion of previous code, sometimes referred to as legacy
code, can reduce
development efforts and risk.

EXAM TIP The use of legacy code in current projects does
not exempt that code
from security reviews. All code should receive the same
scrutiny, especially
legacy code that may have been developed prior to the adoption
of secure
development lifecycle (SDL) processes.
Single Point of Failure
The design of a software system should be such that all points
of failure are
analyzed and that a single failure does not result in system
failure. Examining
designs and implementations for single points of failure is
important to prevent
this form of catastrophic failure from being released in a
product or system.
Single points of failure can exist for any attribute,
confidentiality, integrity,
availability, etc., and may well be different for each attribute.
During the design
phase, failure scenarios should be examined with an eye for
single points of
failure that could cascade into entire system failure.
Interconnectivity
Communication between components implies a pathway that
requires securing.
Managing the communication channel involves several specific
activities. Session

management is the management of the communication channel
itself on a
conversation basis. Exception management is the management
of errors and the
recording of critical information for troubleshooting efforts.
Configuration
management is the application of control principles to the actual
operational
configuration of an application system. These elements work
together to manage
interconnectivity of the elements that comprise the overall
application.
Session Management
Software systems frequently require communications between
program
elements, or between users and program elements. The control
of the
communication session between these elements is essential to
prevent the
hijacking of an authorized communication channel by an
unauthorized party.
Session management is the use of controls to secure a channel
on a conversation-
by-conversation basis. This allows multiple parties to use the
same
communication method without interfering with each other or
disclosing
information across parties.
Designing session management into a system can be as simple
as using
Hypertext Transfer Protocol Secure (HTTPS) for a
communication protocol
between components, or when that is not appropriate,

replicating the essential
elements. Individual communications should be separately
encrypted so cross-
party disclosures do not occur. The major design consideration
is where to
employ these methods. Overemployment can make a system
unnecessarily
complex; underemployment leaves a system open to hijacking.
Exception Management
All systems will have failures; it is why error checking and
failure modes are
important to security. When the software encounters a failure,
communicating
with the user and logging the failure condition are important to
the security of
the application. As mentioned earlier, it is important to
communicate the proper
information so that failures can be diagnosed and corrected. It is
also important
to ensure that there is no information leakage in the process of
recording the
critical information.
During the design phase, it is important to consider the process
of failures and
communications associated with them. This is called exception
management.
Failures should be anticipated, and planned response
mechanisms should be part
of the overall system design. Building in a secure exception
management process
improves overall usability and security.

Configuration Management
Dependable software in production requires the managed
configuration of the
functional connectivity associated with today’s complex,
integrated systems.
Initialization parameters, connection strings, paths, keys, and
other associated
variables are typical examples of configuration items. The
identification and
management of these elements are part of the security process
associated with a
system.
During the design phase, the configuration aspect of the
application needs to
be considered from a security point of view. Although
configuration files are well
understood and have been utilized by many systems,
consideration needs to be
given to what would happen if an adversary was able to modify
these files.
Securing the configuration of a system by securing these files is
a simple and
essential element in design.
Interfaces
Applications operate in a larger enterprise environment. As
previously discussed,
it is advantageous to use enterprise resources for the
management of security.
During the design phase, it is incumbent upon the design team
to determine the
level and method of integration with enterprise resources.

Logging provides the
data, but the design team needs to plan how this data can be
accessed by the
security team once the application is in operation. There are a
variety of ways
that access to the data can be handled—management consoles,
log interfaces, in-
band vs. out-of-band management—each with advantages and
limitations. In
most cases, a combination of these techniques should be
utilized.
In-band management offers more simplicity in terms of
communications. But it
has limitations in that it is exposed to the same threats as the
communication
channel itself. Denial of service attacks may result in loss of the
ability to control
a system. If an adversary sniffs the traffic and determines how
the management
channel works, then the security of the management channel
becomes another
problem. Out-of-band management interfaces use a separate
communication
channel, which may or may not solve the previous
communication issues.
Properly provisioned, out-of-band management allows
management even under
conditions where the app itself is under attack. The
disadvantage to this approach
is that separate, secure communication channels need to be
designed.

Creating a separate management interface to allow users to
manage security
reporting is an additional functionality that requires resources
to create. The
advantage is that the interface can be designed to make the best
presentation of
the material associated with the application. The limitation is
that this
information is in isolation and is not naturally integrated with
other pertinent
security information. Sending the information to the enterprise
operational
security management system—typically a security information
and event
management system—has many advantages. The security
operations personnel
are already familiar with the system, and information can be
cross-correlated
with other operational information.
The important aspect of interfacing the security functionality
with the
enterprise is in the deliberate design to meet security objectives.
Ensuring a solid
design for successful integration into the enterprise security
operations will
enable the customer to minimize the risks of using the
application.
Chapter Review
In this chapter, we examined the use of the core concepts of
confidentiality,
integrity, availability, authentication, authorization, and
auditing as part of a
security-focused design process. The secure design principles

and their role in
designing a secure application were considered. The
interconnectivity
components of session management, exception management, and
configuration
management were examined with respect to designing essential
components.
Quick Tips
• Including confidentiality, integrity, and availability concepts
in an application
and understanding what the specific requirements are for each
of these elements
help provide an essential foundation for software.
• Authentication needs to be designed into the system, as this
function is a
precursor to other aspects of security functionality.
• Whenever possible, the use of enterprise-level functionality
for security
functions, such as authentication, authorization, and logging,
provide enterprise-
level operational benefits.
• When logging information associated with a failure or error,
care must be taken
to not disclose any sensitive information in logs.
• During the design phase, the attack surface analysis and
threat model provide
information as to the elements that need to be secured in the
application.

• Secure design principles can be employed to assist in the
development of a
comprehensive security solution for an application.
• Design attention should be paid to critical foundational
elements such as
configuration management, exception management, and session
management.
Questions
To further help you prepare for the CSSLP exam, and to provide
you with a feel
for your level of preparedness, answer the following questions
and then check
your answers against the list of correct answers found at the end
of the chapter.
1. The primary source of security information for the design
phase of an
application will be contained in the:
A. Configuration file
B. Threat model
C. Security controls analysis
D. Bug tracking database
2. Designing overlapping mitigations to reduce the chance of
failure is an example
of:

in-one/9781260441697/ch9.xhtml#ch9qus_1
A. Complete mediation
B. Least common mechanism
C. Defense in depth
D. Open design
3. Reusing components to reduce risk is an example of:
A. Leverage existing components
B. Separation of duties
C. Weakest link
D. Least common mechanism
4. The use of standardized design functions for similar or
repeated functionality is
referred to as:
A. Psychological acceptability
B. Complete mediation
C. Open design
D. Economy of mechanism
5. Security management interfaces in an application are best

served by:
A. Logging exception data
B. Integration into existing enterprise security management
systems
C. Exception management systems
D. Separate management interface within the application
6. Out-of-band management interfaces solve which of the
following problems?
A. Require separate communication channel
B. Require less bandwidth
C. Reduce development risks
D. Reduce operational risks
7. Designing a secure communication channel system based on
separate
conversations is referred to as:
A. Configuration management

B. Exception handling
C. Confidentiality-based communications
D. Session management
8. Complete mediation is an approach to security that includes:
A. Design using defense in depth and least privilege
B. A security design that minimizes the opportunity to be
circumvented
C. The design of layered security to provide overlapping
defenses
D. The integration with enterprise security elements of
authentication and
authorization
9. Exception management is involved in the management of:
A. Audit data
B. Confidentiality, integrity, and availability (CIA) data

C. Psychological acceptability
D. Separation of duties
10. Hash functions are commonly employed with respect to:
A. Authorization systems
B. Authentication controls
C. Integrity checking
D. Confidentiality controls
11. Logging of errors and failure information should be
designed to protect:
A. Sensitive information
B. Availability through resilient controls
C. Separation of duties
D. Fail-safe designs
12. Designing a system so all parties can easily understand
design objectives and
maintaining a simple design embrace the principle of?
A. Single point of failure
C. Fail safe
D. Open design

13. The use of legacy code improves development efficiency
through reduced
development time, but still requires:
B. Defense in depth
C. Exception management
D. Complete security testing
14. The security principle of fail safe is related to:
A. Session management
B. Exception management
C. Complete mediation
D. Single point of failure
15. Using the principle of keeping things simple is related to:
A. Defense in depth

C. Economy of mechanism
D. Least privilege
Answers
1. B. The threat model is the primary mechanism to
communicate information
about threats, vulnerabilities, and mitigations in an application.
2. C. Defense in depth is accomplished by the design of
overlapping mitigations.
in-one/9781260441697/ch9.xhtml#ch9qus1
3. A. Leveraging existing components reduces risk by using
proven elements.
4. D. Reusing components is an example of economy of
mechanism.
5. B. Integration into the enterprise security management
system provides many
operational benefits to an organization through increased
operational

efficiencies.
6. D. Out-of-band management interfaces are less prone to
interference from denial
of service attacks against an application, reducing operational
risk from loss of
management control.
7. D. Session management involves encrypting
communications on a conversation-
by-conversation basis.
8. B. Complete mediation involves the verification of authority
prior to use to avoid
being circumvented.
9. A. Exception management is the management of log or audit
data.
10. C. Hash functions are used to verify integrity.
11. A. When logging informati on, care should be taken to
prevent the inadvertent
disclosure of sensitive information.
12. D. Open design is all about communicating the design in
clear, simple terms to all
members of the design team.
13. D. Legacy code may not have been developed using an
SDL, so it still requires
complete security testing.
14. B. The principle of fail safe means that when failure
occurs, the system should
remain in a secure state and not disclose information. Exception

management is
the operational tenet associated with fail safe.
15. C. The principle of economy of mechanism means to limit
complexity to make
security manageable, or keep things simple.
https://learning.oreill y.com/library/view/csslp-certification-all-

Title of Assignment
Name of Selected Company
Student Name
Class Name and Number
Professor Name
Month Date Year
Instructions
- Delete this page before submitting assignment.
Review assignment instructions located in Week 9.
Delete the Red instructions throughout and customize before
submitting PowerPoint
Speaker Notes:
Speaker notes should be WRITTEN speaker notes. Do
NOT record or add audio or video files.
Template Design:
Do not change the template design. (Template color changes,
font size/type changes are permitted)
Images:
Add no more that six low resolution images
If you submit this assignment with audio or video files, or if it
exceeds what Blackboard, can accept, your assignment will be
returned with a ZERO, you will need to delete and resubmit.
Blackboard cannot process large files.
Citations:
SWS in-text and source list citations must be used.
In-text citation MAY be placed on the slide if desired, but
MUST be included in the written speaker notes
Summarized, paraphrased and quoted work MUST include an in-
text citations are required.
The full source list citation MUST be included on the last page

of the slide presentation and number in the order used in the
presentation.
In-text citation should be included onto the slide itself. Also,
references, in-text citations, etc. must be included in speaker
notes. Reference https://library.strayer.edu/sws/in-text for
instruction on using in-text citations.
Slide Instruction
Put into your own words bullet points that capture the key
information you want to convey.
Find evidence to support the position/information you have
shared,
Speaker’s Note Instruction
Write out your speaker's notes as if you presenting this
information to a group. [DO NOT RECORD YOUR VOICE OR
ADD AUDIO FILES]
include an in-text citation to give credit to the source.
Include the reference in your source list page
Note: The In-text citation should be included onto the slide
itself as well as the speaker’s note.
Use the Citation
Generator https://library.strayer.edu/sws/generator to
automatically create SWS formatted in-text and source list
citations
Reference https://library.strayer.edu/sws/in-text for instruction
on using in-text citations.

2
Assignment Prompts Approach Example
- Delete this page before submitting assignment.
Answering the Prompts:
Consider rephrasing the prompts in the form of a question to
guide your research into the prompt and/or your response.
Consider using the ACE method:: Answer the question, Cite the
evidence, Explain how the evidence supports your response.
Prompt 1: Summarize your chosen company's Supplier
Responsibility information.
If applicable, find evidence to support response, make note of
the reference and include on source list page.
Prompt 2: In your own words, explain how each aspect of your
Supplier Code of Conduct is committed to ethical business
practices and social responsibility.
Be sure to address what parts of the supplier code of conduct let
you know the company is committed to ethical business
practices and social responsibility.
Prompt 3: Discuss your company's stance on each of the
following areas: • Empowering Workers. • Labor and Human
Rights. • Health and Safety. • The Environment. •
Accountability. (1 -2 slides ONLY)
Prompt 4: Identify the key ways that your company's Code of
Conduct has changed since last year.
Could be called code of ethic or similar name. May also be
found within the company’s annual report.
Prompt 5: Examine the manner in which your company's
Supplier Code of Conduct helps the organization operate as a
socially responsible organization.
Be sure to address the way(s) the Supplier Code of Conduct
helps the company operate in a socially responsible manner.
Prompt 6: In this week's discussion, you consider assembling a
team to write a supplier code of conduct. Recommend the
stakeholders roles (4–5) needed on the team and how each

supports the project.
Note: This prompt is similar to your week 9 discussion post
Prompt 1: Summarize your chosen company's Supplier
Responsibility information. Customize this heading.
Enter first idea of slide here
Enter second idea of slide here
Enter third idea of slide here
(customize your bullet points)
4
Prompt 2: In your own words, explain how each aspect of your
Supplier Code of Conduct is committed to ethical business
practices and social responsibility – Customize this heading.
(customize your bullet points)
5
Prompt 3: Discuss your company's stance on each of the
following areas: Customize this heading. NOTE: Prompt 3 – no
more than two slides
Empowering Workers
Labor and Human Rights

Health and Safety
The Environment
Accountability
6
Prompt 4: Identify the key ways that your company's Code of
Conduct has changed since last year - Customize this heading.
7
Prompt 5: Examine the manner in which your company's
Supplier Code of Conduct helps the organization operate as a
socially responsible organization - Customize this heading.
8
Prompt 6: In this week's discussion, you consider assembling a
team to write a supplier code of conduct. Recommend the
stakeholders roles (4–5) needed on the team and how each
supports the project Customize this heading.

9
Sources
Renumber/reorder source list in the order source was used in
your presentation
Anne Lawrence. 2020. Business and Society: Stakeholders,
Ethics, Public Policy. BUS475 McGraw-Hill Irwin 16th edition
textbook.
Enter the first source entry here.
Enter the second source entry here.
A source list is required. Note: The text book is a required
reference. A standalone URL is not acceptable as a source
reference.
Use the Citation
Generator https://library.strayer.edu/sws/generator to
automatically generate.
Reference https://library.strayer.edu/sws/source for instructions
on creating the source list or
10
CHAPTER 8
Design Processes

• Examine the concept of attack surfaces and attack surface
minimization
• Examine the use of threat modeling to reduce vulnerabilities
• Examine the integration of enterprise security controls to
mitigate threats in
software
• Explore risks associated with code reuse
• Learn how security gate reviews can use threat modeling and
attack surface
information to improve security
Security implementation begins with requirements, and becomes
built in if
designed in as part of the design phase of the secure
development lifecycle (SDL).
Designing in the security requirements enables the coding and
implementation
phases to create a more secure product. Minimization of
vulnerabilities is the
first objective, with the development of layered defenses for
those that remain
being the second objective. To achieve these goals, the software
development
team needs to have a detailed understanding of the specific
threats and
vulnerabilities in the software under development.
Attack Surface Evaluation
The attack surface of software is the code within the system that
can be accessed

by unauthorized parties. This is not just the code itself, but can
also include a
wide range of resources associated with the code, including user
input fields,
protocols, interfaces, resource files, and services. One measure
of the attack
surface is the sheer number or weighted number of accessible
items. Weighting
by severity may change some decision points, but the bottom
line is simple. The
larger the number of elements that can be attacked, the greater
the risk. The
attack surface of software does not represent the quality of the
code—it does not
mean there are flaws; it is merely a measure of how many
features/items are
available for attack.
A long-standing security practice is not to enable functionality
that is not used
or needed. By turning off unnecessary functionality, there is a
smaller attack
surface and there are fewer security risks. Understanding the
attack surface
throughout the development cycle is an important security
function during the
development process. Defining the attack surface and
documenting changes helps
enable better security decision making with respect to
functionality of the
software.
Software is attacked via a series of common mechanisms,

regardless of what
the software is or what it does. Software is attacked all the time,
and in some
remarkably common ways. For instance, weak access control
lists (ACLs) are a
common attack point, and these can be regardless of the
operating system.
Attacks against the operating system can be used against many
applications,
including software that is otherwise secure. Attack surface
evaluation is a means
of measuring and determining the risks associated with the
implications of
design and development.
Attack Surface Measurement
To understand a product’s attack surface, you need to measure
the number of
ways it can be “accessed.” Each software product may be
different, but they will
also share elements. Like many other security items, the first
time a team builds a
list, it will be more difficult. But, over time, the incremental
examination will
detail more items, making future lists easier to develop. In this
light, here is a
published list from Microsoft on attack surface elements
associated with
Windows. Although this list may not be totally applicable, it
does provide a
starting point and acts as a guide of the types of elements
associated with an
attack surface.
• Open sockets

• Open remote procedure call (RPC) endpoints
• Open named pipes
• Services
• Services running by default
• Services running as SYSTEM
• Active web handlers (ASP files, HTR files, and so on)
• Active Internet Server Application Programming Interface
(ISAPI) filters
• Dynamic webpages (ASP and such)
• Executable virtual directories
• Enabled accounts
• Enabled accounts in admin group
• Null sessions to pipes and shares
• Guest account enabled
• Weak ACLs in the file system
• Weak ACLs in the registry
• Weak ACLs on shares

Another source of information is in the history of known
vulnerabilities
associated with previous developments. Determining the root
cause of old
vulnerabilities is good for fixing them and preventing future
occurrences, and it
is also valuable information that can be used in determining the
attack surface.
The list of features that form the attack surface is the same list
that attackers
use to attack a specific piece of software. The items on the list
are not necessarily
vulnerabilities, but they are items that attackers will attempt to
compromise.
These elements are at the base of all vulnerabilities, so while a
particular
vulnerability may or may not exist for a given attack surface
element, there will
be one under each vulnerability that is uncovered. This makes
measuring the
attack surface a solid estimation of the potential vulnerability
surface.
It is important to note that each software product is different,
and hence,
comparing attack surface scores from different products has no
validity. But
counting and measuring the attack surface provides baseline
information from
which security decisions can be made. Different elements may
have different
scoring values, as a service running as a system is riskier than a

nonprivileged
service. Services that are run by default are riskier than those
on the same level
only running on demand.
Attack Surface Minimization
The attack surface is merely a representation of the potential
vulnerability
surface associated with the software. Once a baseline is known,
the next step is to
examine ways that this metric can be lowered. This can be done
by turning off
elements not needed by most users, as this reduces the default
profile surface.
Services that are used can be on or off by default, only on when
needed, run as
system, or without privilege. The lower the privilege, the less a
service is running,
so these factors can reduce the attack surface.
Attack surface minimization is not necessarily an “on or off”
proposition. Some
elements may be off for most users, yet on for specific user s
under appropriate
circumstances. This can make certain features usable, yet not
necessarily
exploitable. Reducing the exposure of elements to untrusted
users can improve
the security posture of the code. Minimization is a form of least
privilege, and the
application of it works in the same manner. If the application is
network aware,
restricting access to a set number of endpoints or a restricted IP
range reduces
the surface.

The attack surface should be calculated throughout the
development process.
Work done to reduce the attack surface should be documented
throughout the
process. This will assist in lowering the default surface level at
deployment, but
the information can also be provided to the customer so they
can make informed
decisions as they determine specific deployment options. As
with all changes, the
earlier in the development process a change is made, the lesser
the impact will be
to surrounding elements.
Attack surface minimization should be considered with design
efforts.
Determining the design baseline and listing the elements and
details assist the
development team in achieving these objectives. As the process
continues and
decisions are made that affect the surface, the documentation of
the current
attack surface area helps everyone understand the security
implications of their
specific decisions. Although security may not be easy to
measure directly, the use
of the attack surface as a surrogate has shown solid results
across numerous
firms.
Threat Modeling
Threat modeling is a process used to identify and document all

of the threats to a
system. Part of the description will include the mitigating
actions that resolve the
exposure. This information is communicated across all members
of the
development team, and acts as a living document that is kept
current as the
software progresses through the development process.
Performing threat
modeling from the beginning of the development process helps
highlight the
issues that need to be resolved early in the process, when it is
easier to resolve
them. Threat modeling is an entire team effort, with everyone
having a role in the
complete documentation of the threats and issues associated
with the software.
Threat Model Development
The threat model development process is a team-based process.
The threat model
development occurs across several phases. The first is defining
the security
objectives for the system. Following that is the system
decomposition, then the
threat identification, followed by mitigation analysis. The final
step is the
validation of the model.
Identify Security Objectives
As part of the requirements process, one of the essential
elements is the
determination of the security objectives associated with the
system under

development. These requirements can come from a number of
sources, including
legal, contractual, and corporate standards and objectives. Both
security and
privacy elements can be considered. Documenting an
understanding of the
business rationale for obtaining and storing data; how it will be
used; and the
related laws, regulations, and corporate standards for such
behaviors will assist
in later stages in the understanding of what is required. Leaving
the decision of
what data to protect and how to protect it up to a development
team is a mistake,
as they may not have the breadth or depth of knowledge with
respect to these
requirements to catch all of the possible associated threats.
Laws, regulations,
contractual requirements, and even corporate standards can be
complex and
byzantine, yet if they are to be properly covered, they need to
be enumerated as a
list of requirements for the development effort.
System Decomposition
Once the security objectives are defined for a system, designers
need to ensure
they are covered in the actual design of the system. Numerous
modeling systems
are used in the design of a system. Unified Modeling Language
(UML), use cases,
misuse cases, data flow diagrams (DFDs), and other methods

have been used to
define a system. For the purposes of threat modeling, since the
target is typically
the information being manipulated, the DFD model is the best
choice to use in
documenting the threats.
Beginning in the design phase, as part of a system
decomposition exercise, the
designers can use DFDs to document the flow of data in the
system. When using
DFDs, it is important to identify and include all processes, data
stores, and data
flows between elements. Special attention should be given to
trust boundaries,
where data crosses from one zone of trust to another. In large,
complex systems,
breaking down the DFD into scenario-based pieces may make
documentation
easier. Every assumption and every dependency should be
enumerated and
described. This is the baseline of the document. As the
development process
progresses, any changes to the items in the threat model should
be documented
and updated.
Trust boundaries are key elements, as they represent points
where an attacker
can interject into the system. Inside a trust boundary, items
share the same
privileges, rights, access, and identifiers. Machine boundaries
are obvious trust
boundaries, but inside a system, if privilege changes, this is a
trust boundary, too.

DFD Elements for Threat Modeling
The following are examples of elements to identify as part of
the threat modeling
process:
External Entities
• Users (by type)
• Other systems
Data Stores
• Files
• Database
• Registry
• Shared memory
• Queues/stack
Trust Boundaries
• Users
• File systems
• Process boundaries
Data Flows

• Function calls
• Remote procedure calls (RPCs)
• Network traffic
Threat Identification
Once the system is well documented, then the process of
identifying threats
begins. Threat identification can be done in a variety of
manners, and in most
cases, several methods will be used. An experienced security
person can provide
a series of known threats that are common across applications,
although this list
needs to be tailored to the application under development.
During the DFD
documentation process, as security objectives are documented,
the question of
what issues need to be protected against is answered, and this
information
describes threats. The use of the STRIDE method can be
repeated across
processes, data flows, trust boundaries—anywhere you want to
understand the
security implications of that portion of the application under
development. Using
each of the elements of STRIDE, the threat model is
documented as to what
happens as a result of each element of the STRIDE acronym.
Not every STRIDE
element will warrant documenting at every location, but this
exercise will

uncover many important security considerations.
As the threats are enumerated and documented, try to avoid
becoming
distracted by things that the application cannot control. For
instance, if the
system administrator decides to violate the system (machine)
trust, this is an
operating system issue, not an application issue. Likewise, with
elements such as
“someone steals the hard drive,” other than encrypting essential
data at rest, this
is an outside-the-application issue.
By this point, a lot of data will be associated with the threat
model. There are
tools to assist in the collection and manipulatio n of the threat
model data, and it
is wise to use an automated tool to manage the documentation.
All of the
described elements up to this point need to be numbered,
categorized, and
managed in some fashion. The next step is an examination of
mitigations that can
be employed to address the threats.
STRIDE
The acronym STRIDE is used to denote the following types of
threats:
Mitigation Analysis

Each threat requires mitigation. Mitigation can be of four types:
redesign to
eliminate vulnerability, apply a standard mitigation, invent a
new mitigation, or
accept the vulnerability. If redesign is an option, and it may be
in the early parts
of the development process, this is the best method, as it
removes the risk. The
next best method is to apply a standard mitigation. Standard
mitigations are
common security functions, such as ACLs, and have several
advantages. First,
they are well understood and are known to be effective. Second,
in many cases,
they will apply across a large number of specific vulnerability
points, making
them an economical choice. Developing new mitigation methods
is riskier and
more costly, as it will require more extensive testing. Accepting
the
vulnerabilities is the least desired solution, but may on occasion
be the only
option.
The threat model is a dynamic document that changes with the
development
effort; so, too, do the mitigations. For a threat that is
documented late in the
development cycle, elements such as redesign may not be
practical for this
release. But the information can still be documented, and on the
next release of
the software, redesign may be an option that improves the
security.
In picking the appropriate mitigation, one needs to understand

the nature of
the threat and how it is manifested upon the system. One tool
that can assist in
this effort is an attack tree model. An attack tree is a graphical
representation of
an attack, beginning with the attack objective as the root node.
From this node, a
hierarchical tree-like structure of necessary conditions is listed.
Figure 8-
1 illustrates a simple attack tree model for an authorization
cookie.
in-one/9781260441697/ch8.xhtml#ch8fig1
FIGURE 8-1 Attack tree
When describing a threat, it is also useful to gauge the priority
one should
place on it. Some attacks are clearly more serious than others,
and risk
management has dealt with this using probability and impact.
Probability
represents the likelihood that the attack will have success. This
is not necessarily
a numerical probability, but typically is described using
nominal values of high,
medium, and low. Impact represents the loss or risk faced by a
successful attack,
and it, too, is frequently scored as high, medium, or low. To
convert these to a
numerical score, you can apply numbers (high = 3, medium = 2,

low = 1) to each
and multiply the two. The resulting scores will be between 9
and 1. This provides
a means of differentiating threats, with those scoring higher
clearly more
important to address.
Another method is referred to as DREAD, with DREAD being
an acronym for
damage potential, reproducibility, exploitability, affected users,
and
discoverability. To use DREAD, one can assign a value from 0
(nothing), to 5
(moderate), to 10 (severe) for each of the elements. Then the
total risk can be
obtained by summing and dividing by 5, which will yield a
score from 0 to 10.
Another method is to set discoverability to 10, assuming
discovery when doing
the analysis. DREAD can be mapped into the probability impact
model by taking
the following factors into account: probability (reproducibility
+ exploitability +
discoverability) and impact (damage potential + affected users).
Threat Model Validation
As the software development process moves through the phases
of the SDL, at
gates between the phases, an opportunity to examine materials
presents itself.
The current version of the threat model should be validated at
each of these

opportunities. The purpose of the validation phase is to assess
the quality of the
threats and mitigations. For the threats, it is important to ensure
that they
describe the attack and the impact in detail relevant to the
context of the
application. For mitigations, it is important that they are
associated with a threat
and are completely described in terms relevant to the context of
the application.
Any and all dependencies should be documented. Documenting
both what
other code bases you are relying on and the security functions
associated with
that code is important. Ensuring all dependencies are
documented is important at
each phase of the SDL. Any assumptions that are made as part
of the
development process are also important to document.
Control Identification and Prioritization
Security controls are the primary mechanisms that enterprises
use to manage
security. These controls form the backbone of the enterpri se
security function
and can be applied as part of the mitigation package for the
application under
development. Using enterprise controls such as ACLs
implements security
mitigations and does so in a manner where the enterprise can
operationally
perform the tasks efficiently and correctly.
Priority should be afforded to any security control that exists in

the enterprise.
Although some applications may have the ability to maintain
their own access
control mechanism, managing the security of the user base adds
duplicative
work. Aligning the access control, user authentication, and
other security
mechanisms to those employed in the enterprise reduces the
operational security
workload and still achieves the desired mitigating actions.
Software programs and applications do not exist in a vacuum.
Part of the
Microsoft SDL process is to have systems be secure by design,
by default, and in
deployment. Using design elements to ensure integration into
appropriate
enterprise security controls assists in these objectives. Use of
security provisions
of existing protocols, such as IPSec, Hypertext Transfer
Protocol Secure (HTTPS),
Secure Shell (SSH), and others, can provide significant security
mitigation efforts
that are supported by the platform and the enterprise and are
optimally
managed. Reducing any duplication of security functionality
reduces
development risks and improves deployment and operations of
the software.
Risk Assessment for Code Reuse
Code reuse has been a practice in the software development

industry since its
beginning. The reasons are many: saving time, reducing work,
and providing
consistency. Software libraries are the ultimate example of code
reuse. However,
code reuse does not come without risk. Reuse of older code has
resulted in errors
in the past and will do so again in the future. Legacy code from
products as old as
Windows for Workgroups has resulted in security issues in
products up to
Windows XP.
When old code is reused in a project, it should be subjected to
the same
scrutiny as the new code under development. Old code should
be included in
threat modeling and attack surface minimization efforts. Code
reviews and
walkthroughs can provide valuable insight into risks associated
with legacy code.
Vulnerabilities that did not exist in the code at the time it was
developed can
arise due to changes in the environment that the code operates
in. Examining the
code in the context of the current operating environment can
reveal issues that
would not have been discoverable in the original environment.
Documentation
The documentation associated with threat modeling and attack
surface
minimization provides a wealth of security-related information.
Keeping this
documentation up to date is not just a paperwork exercise to

satisfy an auditor or
regulation, but provides value as a roadmap and encyclopedic
repository for
team use.
The purpose of the documentation is to communicate essential
information
across the development team. Beginning with requirements and
progressing all
the way through the development process, the information
compiled in the
documentation provides a guide to keep all team members on
the same plane
throughout. As each new phase of the development process is
started, the
documentation provides a running narrative of the security
issues that have been
identified, the plans to mitigate, and the expectations of the
development process
with regard to achieving these objectives. As the attack surface
area is always a
dynamic issue, each phase should monitor this issue and keep
the plan updated
with current options and measurements. Making this an issue
that is tracked
helps draw attention to subtle creep that increases this risk
without a full
understanding of the causes and ramifications.
In this same vein, the threat model documentation provides a
wealth of
detailed information concerning security objectives, an
enumeration of threats,

how vulnerabilities and mitigations are being handled, and
documentation on
dependencies and assumptions. This information can be used by
the software
development team to ensure that issues are not overlooked or
that design
elements are not providing the best platform options for
minimizing security
risk. As with other aspects of the security documentation, the
living nature of the
threat model portion is, by design, encouraging improvement of
the threat model
at every step of the development process. Keeping the team
aware of and focused
on what can be done to mitigate the specific vulnerabilities
enables the entire
team to assist in creating the most secure implementation
possible.
Design and Architecture Technical Review
Using the results of the documentation from the attack surface
area and the
threat model enables the development team to properly design
and implement
security functionality in the application under development.
Periodic reviews of
the development progress should include reviews of the security
progress as well.
Code walkthroughs, design reviews, examination of the attack
surface area, and
threat modeling documentation with an eye toward
completeness are key
elements of these reviews.
The periodic reviews are not just technical to ensure that the

products of the
SDL process are technically complete and accurate, but are also
process focused.
Equally important is the notion that the SDL process is
functioning as planned to
achieve the desired objectives. The security review process is
really a two-
pronged effort. The primary effort needs to be done by the
development team
during each phase of the development process. Security cannot
be added in after
the fact by the security team, but instead must be baked into the
product as part
of the development effort. The attack surface minimization and
threat modeling
efforts provide a process-wide vehicle for managing these
issues and building
security into the application. The SDL process is designed to
specifically support
this effort. As part of the review efforts at every level, ensuring
that proper
attention is being devoted to the security posture is the entire
team’s
responsibility. The primary function of the security review at
the process gates is
to ensure that this activity is occurring and performing at the
desired levels.
Thus, the security review is oriented to the process, not just to
ensuring that all of
the security bases are being covered.
Chapter Review

This chapter opened with an examination of attack surfaces and
how they play a
role in security software. The chapter continued the coverage of
attack surfaces,
examining how they are defined, measured, and ultimately
minimized. This
information is documented in a report that is updated
throughout the
development process. Threat modeling was presented as the tool
and mechanism
used to understand and mitigate the threats against the
application. A detailed
examination of how threat modeling is performed, what is
documented, and how
the information is used to reduce vulnerabilities was presented.
The integration
of threat modeling continued with a discussion of the risks
associated with code
reuse and an examination of how security controls are used to
improve security
in the product.
The chapter concluded with an examination of how the
documentation from
the attack surface and threat modeling efforts can be used to
achieve team
coordination in the pursuit of application security objectives.
Quick Tips
• The attack surface of an application represents a measure of
how many
features/items are available for attack.
• The actual measure of an attack surface is useful across the
development process

to measure improvement on numbers of potential
vulnerabilities.
• Threat modeling is a process used to identify and document
all of the threats to a
system.
• Threat modeling has five phases: define security objectives,
system
decomposition, threat enumeration, mitigation analysis, and
validation of the
model.
• STRIDE represents spoofing, tampering, repudiation,
information disclosure,
denial of service, and elevation of privilege.
• Attack trees provide causal information with respect to
attack vectors.
• DREAD represents damage potential, reproducibility,
exploitability, affected
users, and discoverability.
• When securing vulnerabilities, priority should be afforded to
any security control
that exists in the enterprise.
• Attack surface and threat modeling documentation are living
documents to
communicate security information across the development team.
Questions

you with a feel
and then check
of the chapter.
1. The increasing value for the attack surface of an application
during development
is indicative of:
A. Excess risk
B. Declining code quality
C. An increase in addressable resources
D. An improvement in security
2. You have moved to a new project, and the attack surface
measurement indicates
an attack surface only half of the value of the project you just
left. This indicates:
A. More work on minimization is needed.
B. The previous project was more secure from a security
perspective.
C. The previous project was twice as big; no problem.

D. Nothing. Attack surface measurements are not comparable
across different
projects.
3. The attack surface of your project seems to grow faster than
it should. Which of
the following is probably not a fruitful place to look?
A. Number of modules/routines in the project
B. Privilege level of the credentials used to run the application
C. Network address space from which the program is
addressable
D. Privilege level of users using the application
4. The first step in threat modeling is:
A. Define security objectives for the application.
B. Pick a threat model team.
C. Decompose the application into smaller pieces.
D. Measure the attack surface of the application.
5. STRIDE stands for:
A. Spoofing, trust violation, repudiation, information
disclosure, denial of service,
elevation of privilege
B. Spoofing, tampering, repudiation, information disclosure,
denial of service,

C. Spoofing, tampering, reproducibility, information
D. Spoofing, tampering, repudiation, information disclosure,
denial of service,
exploitability
6. DREAD stands for:
A. Damage potential, reproducibility, exploitability, affected
users, discoverability
B. Damage potential, repudiation, exploitability, affected
C. Damage potential, reproducibility, exploitability, asset
value, discoverability
D. Damage potential, reproducibility, elevation of privilege,
affected users,
discoverability
7. Inside a trust boundary, items:
A. Share the same ACL access

B. Share the same privileges, rights, access, and identifiers
C. Share the same user account
D. Are not observable
8. A threat model is validated for all of the following except:
A. Appropriate mitigations are assigned to all threats listed.
B. All security threats are identified.
C. Dependencies have been considered and are documented.
D. The quality of mitigations is adequate.
9. To reduce the risk associated with reusing code, the
development team should:
A. Never reuse code, but develop all code via the SDL process
B. Identify and document the risk of reused code
C. Perform testing and validation on reused code in the same
fashion as new code
D. Only use code certified for the project

10. If there is not sufficient time to finish the threat model
documentation, the team
should:
A. Request a waiver from the security team
B. Push the documentation into the next phase as an item to be
finished
C. Delay the gate until the documentation is complete
D. Don’t worry about the documentation if the work is done
correctly
11. The primary purpose behind security reviews is to:
A. Ensure that all steps of the SDL are being properly
followed
B. Ensure that the attack surface model is updated at each
phase
C. Assess the quality of security actions, including mitigations
for vulnerabilities
D. Ensure that the threat model is updated at each phase
12. The STRIDE model is applied to:
A. Attack surfaces in the attack surface model
B. Threat identification efforts as part of threat modeling

C. Determine the risk from a threat
D. Every threat found during the attack surface area
measurement effort
13. The best method of system decomposition for threat
modeling is the construction
of:
A. Misuse cases
B. Use cases
C. UML
D. DFDs
14. Which of the following is not a mitigation method for
threats identified in threat
modeling?
A. Redesign to eliminate vulnerability.
B. Apply a standard mitigation.
C. Change the security requirements to eliminate the threat.
D. Accept the vulnerability.

15. The preferred security mitigation to use during threat
modeling is:
A. A custom control created specifically for the threat
B. Encryption from an approved library to prevent information
disclosure
C. Acceptance of the vulnerability
D. Standard enterprise-level security controls in common use,
such as ACLs
Answers
1. C. An increase in the value of the attack surface indicates
an increase in the
number of addressable resources.
2. D. Attack surface measurements are defined by the breadth
and scope of
addressable elements, and thus are not strictly comparable
across different
projects.
3. A. The number of modules a program is composed of does
not factor directly into

attack surface calculations.
4. A. Defining the security objectives for an application forms
the foundation for all
threat modeling efforts.
5. B. STRIDE is an acronym for spoofing, tampering,
repudiation, information
disclosure, denial of service, and elevation of privilege.
6. A. DREAD is an acronym for damage potential,
reproducibility, exploitability,
affected users, and discoverability.
7. B. This is the definition of a trust boundary; inside a trust
boundary, items share
the same privileges, rights, access, and identifiers.
8. B. It is never possible to identify all threats to a system.
9. C. Legacy code can be included in new projects, but it
should be subjected to all
of the same security steps and tests as new code.
10. C. The security review should block advancement under
the SDL process until all
aspects of a phase are complete and properly done.
11. A. The primary purpose of security reviews is to assess the
efficacy of the SDL,
with that efficacy having the desired security effects, not the
review itself.
12. B. STRIDE is used during the threat identification phase to
identify types of
threats.

13. D. Data flow diagrams are best suited for the identification
of threats to a system.
https://learning.oreilly.com/librar y/view/csslp-certification-all-
14. C. Changing the security requirements does not eliminate a
threat; it merely
results in it being ignored.

15. D. The preferred set of mitigations are enterprise-level
security controls already
in place and used in the enterprise.
in-one/9781260441697/ ch8.xhtml#ch8qus15
CHAPTER 9
Design Considerations
• Examine how to design security into an application using
core security concepts
• Learn the roles of confidentiality, integrity, and availability
with respect to
designing in information security principles
• Explore designing in security elements using authentication,
authorization, and
auditing
• Explore how to use secure design principles to improve
application security
• Learn how interconnectivity provides opportunities to design
in security
elements

Designing an application is the beginning of implementing
security into the final
application. Using the information uncovered in the
requirements phase,
designers create the blueprint developers use to arrive at the
final product. It is
during this phase that the foundational elements to build the
proper security
functionality into the application are initiated. To determine
which security
elements are needed in the application, designers can use the
information from
the attack surface analysis and the threat model to determine the
“what” and
“where” elements. Knowledge of secure design principles can
provide the “how”
elements. Using this information in a comprehensive plan can
provide developers
with a targeted foundation that will greatly assist in creating a
secure application.
Application of Methods to Address Core Security Concepts
In Chapter 1, we explored the basic principles of security. In
this chapter, we will
examine how to design in security by utilizing these concepts.
The concepts of
confidentiality, integrity, and availability, widely lauded as the
key elements of
information security, do not happen by accident—they must be
designed into the
application to be effective and to provide specific protections.
Confidentiality, Integrity, and Availability

The principles of confidentiality, integrity, and availability are
commonly used in
information security discussions. For these elements to be
effective in an
application, they need to be designed into the application during
the design
phase. This is done by using tools such as encryption, hashing,
and recovery
methods. Encryption can preserve confidentiality by making
information
unavailable to unauthorized parties. Integrity can be ensured
through the use of
hash codes. Designing in proper recovery methods provides for
a more resilient
application that can support higher availability.
Confidentiality
Confidentiality is the concept of preventing the disclosure of
information to
unauthorized parties. Keeping secrets secret is the core concept
of confidentiality.
One of the key elements in the design phase is determining what
elements need
to be kept secret. The threat model will identify those elements.
The next aspect is
to examine the state of the data that is to be kept confidential. If
the data is at rest,
then encryption can be used to restrict access to authorized
users. If the data is in
transit, then encryption can also be used, but the method of
encryption may be
based on the transport method. Data that needs to be kept
confidential in use, i.e.,
encryption keys, will require special attention.

Once the elements are determined, the next part of the
confidentiality
equation is to determine who the authorized parties are. The
concepts of
authorization are covered later in this chapter.
Integrity
Integrity refers to protecting data from unauthorized alteration.
Alterations can
come in the form of changing a value or deleting a value.
Integrity builds upon
confidentiality, for if data is to be altered or deleted, then it is
probably also
in-one/9781260441697/ch1.xhtml#ch1
visible to the user account. Users can be authorized to view
information, but not
alter it, so integrity controls require an authorization scheme
that controls
update and delete operations.
Protecting integrity can be done through the use of access
control mechanisms.
Individual specific levels of access with respect to read, write,
and delete can be
defined. Applying controls is just a piece of the integrity
puzzle. The other aspect
involves determining whether data has been altered or not. In
some cases, this is
just as important, if not more so, as the access control part. To
determine whether

the information has been altered or not requires some form of
control other than
simple access control.
If there is a requirement to verify the integrity of a data element
throughout its
lifecycle, the cryptographic function of hashing can be used.
Hash functions can
determine if single or multiple bits of data change from the
original form. The
principle is simple: Take the original data, run it through a hash
function, and
record the result. At any subsequent time, running the current
value of the data
through the same hash function will produce a current digest
value. If the two
digest values match, then the data is unchanged. This can be for
something small,
such as a few bytes, to an entire file system—in all cases, the
digest size is fixed
based on the hash algorithm.
The design issue is, how does one implement this functionality?
When are hash
digests calculated? How are the digests stored and transmitted
by a separate
channel to the party checking? Adding the necessary elements
to allow hash-
based checking of integrity requires the designing of the
necessary apparatus for
parties to be able to verify integrity. In some cases, like in
Microsoft Update
Service, this entire mechanism is designed into the transfer
mechanism so that it
is invisible to the end user. The design phase is where these
decisions need to be

made so that the coding phase can properly implement the
desired behavior.
Availability
Availability is defined as a system being available to authorized
users when
appropriate. Numerous threats can affect the availability of a
system. The threat
model should provide significant information as to what aspects
of a system need
availability protected and what aspects are not sensitive.
Designing the best
defenses against availability issues depends upon the threat to
availability.
Backups can provide a form of protection, as can data
replication. Failover to
redundant systems can also be employed. The key is in
determining the specifics
of the availability need and expressing them in a requirement
that is then
designed into the system.
Authentication, Authorization, and Auditing
The functions of authentication and authorization are
foundational elements of
employing controls such as access control lists. Designing these
elements into an
application is one where decisions need to be made as to
integration with
existing—i.e., operating system–provided functionality—or
designing and

building a stand-alone system. Auditing or logging is another
system
functionality, essential to security, where a design decision is
needed as to the
level of integration with existing operating system
functionality. In both of these
situations, it might seem easier to build your own system, but
the true
functionality needed in most system environments comes from
integration into
the larger enterprise-level security system, and this means
integration of
authentication, authorization, and auditing functionality into the
existing
operating system functionality.
Authentication
Authentication is the process used to verify to the computer
system or network
that the individual is who they claim to be. It is a key element
in the security of a
system, for if this system is bypassed or spoofed, then all
subsequent security
decisions can be in error. One of the key design questions is the
level of assurance
needed with respect to authentication. If an application is web-
based, where
users need to log in to establish their identity, then the design
and securing of this
information becomes an important part of the security equation.
Authentication
data is highly valuable data to an attacker and needs to be
protected. This shows
the interconnected nature of security, authentication, and
confidentiality issues,

as well as many others.
Authentication systems are complex, and the difficulty in
designing and
implementing them can be a daunting task. Whenever possible,
it is best to leave
authentication to established systems, such as the operating
system. This makes it
easier to integrate with existing operational security systems,
and most operating
system (OS) authentication systems are well tested and vetted.
If the OS method is
not appropriate, such as in web app login systems, then
adherence to proper
security design patterns for authentication systems is essential.
Authorization
After the authentication system identifies a user to a system, the
authorization
system takes over and applies the predetermined access levels to
the user. As
with authentication, authorization systems can be complex and
difficult to
implement correctly. For elements that can be covered by the
operating system
authorization system, i.e., access control lists for critical files
and resources, these
built-in and integrated systems should be utilized. If custom
authorization
elements are needed, they must be carefully designed using
proper security
design patterns for authorization systems.

Accounting (Audit)
Accounting is the function of measuring specific IT activities.
This is typically
done through the logging of crucial data elements of an activity
as it occurs. The
key elements in the design phase are the determination of what
crucial elements
should be logged and under what circumstances. Several sources
of information
can be used for determining what to log and when. The simplest
rule is to include
error trapping in every module and log what developers would
need to
understand the source of the problem. Caution should be
exercised in the logging
of data associated with records in the system. Data records
could contain
sensitive information that should be protected and not exposed
in logs. Should
sensitive data need to be logged, then encryption of the data is
needed to protect
the confidentiality requirements.
NOTE When logging information associated with a failure or
error, care must
be taken to not disclose any sensitive information in logs. This
includes elements
such as personally identifiable information (PII) and
programmatic elements
such as paths and filenames.

Implementing secure design principles requires specific design
elements to be
employed. Using the information from the attack surface
analysis and the threat
model, designers can pinpoint the places where specific design
elements can be
employed to achieve the desired security objectives. Security
controls can be
chosen based on the design to implement the desired levels of
protection per
security requirements. This can include controls to ensure
confidentiality,
integrity, and availability.
The following are secure design principles that are employed to
achieve
application security:
Good Enough Security
When designing in security aspects of an application, care
should be exercised to
ensure that the security elements are in response to the actual
risk associated
with the potential vulnerability. Designing excess security
elements is a waste of
resources. Underprotecting the application increases the risk.
The challenge is in
determining the correct level of security functionality. Elements
of the threat
model and attack surface analysis can provide guidance as to
the level of risk.

Documenting the level and purpose of security functions will
assist the
development team in creating an appropriate and desired level
of security.
Least Privilege
One of the most fundamental approaches to security is least
privilege. Least
privilege should be utilized whenever possible as a preventa tive
measure.
Embracing designs with least privilege creates a natural set of
defenses should
unexpected errors happen. Least privilege, by definition, is
sufficient privilege,
and this should be a design standard. Excess privilege
represents potentially
excess risk when vulnerabilities are exploited.
Separation of Duties
Separation of duties must be designed into a system. Software
components can be
designed to enforce separation of duties when they require
multiple conditions to
be met before a task is considered complete. These multiple
conditions can then
be managed separately to enforce the checks and balances
required by the
system. In designing the system, designers also impact the
method of operation of
the system.

As with all other design choices, the details are recorded as part
of the threat
model. This acts as the communication method between all
members of the
development effort. Designing in operational elements such as
separation of
duties still requires additional work to happen through the
development process,
and the threat model can communicate the expectations of later
development
activities in this regard.
Defense in Depth
Defense in depth is one of the oldest security principles. If one
defense is good,
multiple overlapping defenses are better. The threat model
document will
contain information where overlapping defenses should be
implemented.
Designing in layers as part of the security architecture can work
to mitigate a
wider range of threats in a more efficient manner.
NOTE It’s not that I’m assuming your code will fail. It’s that
I’m assuming all code
can fail, including mine. You are not a special case. – Dan
Kaminsky, security guru
Because every piece of software can be compromised or
bypassed in some
way, it is incumbent on the design team to recognize this and
create defenses that

can mitigate specific threats. Although all software, including
the mitigating
defenses, can fail, the end result is to raise the difficulty level
and limit the risk
associated with individual failures.
Designing a series of layered defense elements across an
application provides
for an efficient defense. For layers to be effective, they should
be dissimilar in
nature so that if an adversary makes it past one layer, a separate
layer may still
be effective in maintaining the system in a secure state. An
example is the
coupling of encryption and access control methods to provide
multiple layers that
are diverse in their protection nature and yet both can provide
confidentiality.
Fail Safe
As mentioned in the exception management section, all systems
will experience
failures. The fail-safe design principle refers to the fact that
when a system
experiences a failure, it should fail to a safe state. When
designing elements of an
application, one should consider what happens when a particular
element fails.
When a system enters a failure state, the attributes associated
with security,
confidentiality, integrity, and availability need to be
appropriately maintained.
Failure is something that every system will experience. One of
the design

elements that should be considered is how the individual
failures affect overall
operations. Ensuring that the design includes elements to
degrade gracefully and
return to normal operation through the shortest path assists in
maintaining the
resilience of the system. For example, if a system cannot
complete a connection to
a database, when the attempt times out, how does the system
react? Does it
automatically retry, and if so, is there a mechanism to prevent a
lockup when the
failure continually repeats?
Economy of Mechanism
The terms security and complexity are often at odds with each
other. This is
because the more complex something is, the harder it is to
understand, and you
cannot truly secure something if you do not understand it.
During the design
phase of the project, it is important to emphasize simplicity.
Smaller and simpler
is easier to secure. Designs that are easy to understand, easy to
implement, and
well documented will lead to more secure applications.
If an application is going to do a specific type of function—for
example, gather
standard information from a database—and this function repeats
throughout the
system, then designing a standard method and reusing it
improves system

stability. As systems tend to grow and evolve over time, it is
important to design
in extensibility. Applications should be designed to be simple to
troubleshoot,
simple to expand, simple to use, and simple to administer.
Complete Mediation
Systems should be designed so that if the authorization system
is ever
circumvented, the damage is limited to immediate requests.
Whenever sensitive
operations are to be performed, it is important to perform
authorization checks.
Assuming that permissions are appropriate is just that—an
assumption—and
failures can occur. For instance, if a routine is to permit
managers to change a
key value in a database, then assuming that the party calling the
routine is a
manager can result in failures. Verifying that the party has the
requisite
authorization as part of the function is an example of complete
mediation.
Designing this level of security into a system should be a
standard design practice
for all applications.
Open Design
Part of the software development process includes multiple
parties doing
different tasks that in the end create a functioning piece of
software. Over time,
the software will be updated and improved, which is another
round of the

development process. For all of this work to be properly
coordinated, open
communication needs to occur. Having designs that are open
and understandable
will prevent activities later in the development process that will
weaken or
bypass security efforts.
Least Common Mechanism
The concept of least common mechanism is constructed to
prevent inadvertent
security failures. Designing a system where multiple processes
share a common
mechanism can lead to a potential information pathway between
users or
processes. The concepts of least common mechanism and
leverage existing
components can place a designer at a conflicting crossroad. One
concept
advocates reuse and the other separation. The choice is a case of
determining the
correct balance associated with the risk from each.
Take a system where users can access or modify database
records based on
their user credentials. Having a single interface that handles all
requests can lead
to inadvertent weaknesses. If reading is considered one level of
security and
modification of records a more privileged activity, then
combining them into a
single routine exposes the high-privilege action to a potential
low-privilege

account. Thus, separating mechanisms based on security levels
can be an
important design tool.
Psychological Acceptability
Users are a key part of a system and its security. To include a
user in the security
of a system requires that the security aspects be designed so
that they are
psychologically acceptable to the user. When a user is presented
with a security
system that appears to obstruct the user, the result will be the
user working
around these security aspects. Applications communicate with
users all the time.
Care and effort are given to ensuring that an application is
useable in normal
operation. This same idea of usability needs to be extended to
security functions.
Designers should understand how the application will be used in
the enterprise
and what users will expect of it.
When users are presented with cryptic messages, such as the
ubiquitous
“Contact your system administrator” error message, expecting
them to do
anything that will help resolve an issue is unrealistic. Just as
care and
consideration are taken to ensure normal operations are
comprehensible to the
user, so, too, should a similar effort be taken for abnormal
circumstances.
Weakest Link

Every system, by definition, has a “weakest” link. Adversaries
do not seek out the
strongest defense to attempt a breach; they seek out any
weakness they can
exploit. Overall, a system can only be considered as strong as
its weakest link.
When designing an application, it is important to consider both
the local and
system views with respect to weaknesses. Designing a system
using the security
tenets described in this section will go a long way in preventing
local failures
from becoming system failures. This limits the effect of the
weakest link to local
effects.
Leverage Existing Components
Modern software development includes extensive reuse of
components. From
component libraries to common functions across multiple
components, there is
significant opportunity to reduce development costs through
reuse. This can also
simplify a system through the reuse of known elements. The
downside of massive
reuse is associated with a monoculture environment, which is
where a failure
has a larger footprint because of all the places where it is
involved.
During the design phase, decisions should be made as to the
appropriate level

of reuse. For some complex functions, such as in cryptography,
reuse is the
preferred path. In other cases, where the lineage of a component
cannot be
established, then the risk of use may outweigh the benefit. In
addition, the
inclusion of previous code, sometimes referred to as legacy
code, can reduce
development efforts and risk.
EXAM TIP The use of legacy code in current projects does
not exempt that code
from security reviews. All code should receive the same
scrutiny, especially
legacy code that may have been developed prior to the adoption
of secure
development lifecycle (SDL) processes.
Single Point of Failure
The design of a software system should be such that all points
of failure are
analyzed and that a single failure does not result in system
failure. Examining
designs and implementations for single points of failure is
important to prevent
this form of catastrophic failure from being released in a
product or system.
Single points of failure can exist for any attribute,
confidentiality, integrity,
availability, etc., and may well be different for each attribute.
During the design
phase, failure scenarios should be examined with an eye for
single points of
failure that could cascade into entire system failure.

Interconnectivity
Communication between components implies a pathway that
requires securing.
Managing the communication channel involves several specific
activities. Session
management is the management of the communication channel
itself on a
conversation basis. Exception management is the management
of errors and the
recording of critical information for troubleshooting efforts.
Configuration
management is the application of control principles to the actual
operational
configuration of an application system. These elements work
together to manage
interconnectivity of the elements that comprise the overall
application.
Session Management
Software systems frequently require communications between
program
elements, or between users and program elements. The control
of the
communication session between these elements is essential to
prevent the
hijacking of an authorized communication channel by an
unauthorized party.
Session management is the use of controls to secure a channel
on a conversation-
by-conversation basis. This allows multiple parties to use the
same

communication method without interfering with each other or
disclosing
information across parties.
Designing session management into a system can be as simple
as using
Hypertext Transfer Protocol Secure (HTTPS) for a
communication protocol
between components, or when that is not appropriate,
replicating the essential
elements. Individual communications should be separately
encrypted so cross-
party disclosures do not occur. The major design consideration
is where to
employ these methods. Overemployment can make a system
unnecessarily
complex; underemployment leaves a system open to hijacking.
Exception Management
All systems will have failures; it is why error checking and
failure modes are
important to security. When the software encounters a failure,
communicating
with the user and logging the failure condition are important to
the security of
the application. As mentioned earlier, it is important to
communicate the proper
information so that failures can be diagnosed and corrected. It is
also important
to ensure that there is no information leakage in the process of
recording the
critical information.

During the design phase, it is important to consider the process
of failures and
communications associated with them. This is called exception
management.
Failures should be anticipated, and planned response
mechanisms should be part
of the overall system design. Building in a secure exception
management process
improves overall usability and security.
Configuration Management
Dependable software in production requires the managed
configuration of the
functional connectivity associated with today’s complex,
integrated systems.
Initialization parameters, connection strings, paths, keys, and
other associated
variables are typical examples of configuration items. The
identification and
management of these elements are part of the security process
associated with a
system.
During the design phase, the configuration aspect of the
application needs to
be considered from a security point of view. Although
configuration files are well
understood and have been utilized by many systems,
consideration needs to be
given to what would happen if an adversary was able to modify
these files.
Securing the configuration of a system by securing these files is
a simple and
essential element in design.

Interfaces
Applications operate in a larger enterprise environment. As
previously discussed,
it is advantageous to use enterprise resources for the
management of security.
During the design phase, it is incumbent upon the design team
to determine the
level and method of integration with enterprise resources.
Logging provides the
data, but the design team needs to plan how this data can be
accessed by the
security team once the application is in operation. There are a
variety of ways
that access to the data can be handled—management consoles,
log interfaces, in-
band vs. out-of-band management—each with advantages and
limitations. In
most cases, a combination of these techniques should be
utilized.
In-band management offers more simplicity in terms of
communications. But it
has limitations in that it is exposed to the same threats as the
communication
channel itself. Denial of service attacks may result in loss of the
ability to control
a system. If an adversary sniffs the traffic and determines how
the management
channel works, then the security of the management channel
becomes another
problem. Out-of-band management interfaces use a separate
communication

channel, which may or may not solve the previous
communication issues.
Properly provisioned, out-of-band management allows
management even under
conditions where the app itself is under attack. The
disadvantage to this approach
is that separate, secure communication channels need to be
designed.
Creating a separate management interface to allow users to
manage security
reporting is an additional functionality that requires resources
to create. The
advantage is that the interface can be designed to make the best
presentation of
the material associated with the application. The limitation is
that this
information is in isolation and is not naturally integrated with
other pertinent
security information. Sending the information to the enterprise
operational
security management system—typically a security information
and event
management system—has many advantages. The security
operations personnel
are already familiar with the system, and information can be
cross-correlated
with other operational information.
The important aspect of interfacing the security functionality
with the
enterprise is in the deliberate design to meet security objectives.
Ensuring a solid
design for successful integration into the enterprise security
operations will
enable the customer to minimize the risks of using the

application.
Chapter Review
In this chapter, we examined the use of the core concepts of
confidentiality,
integrity, availability, authentication, authorization, and
auditing as part of a
security-focused design process. The secure design principles
and their role in
designing a secure application were considered. The
interconnectivity
components of session management, exception management, and
configuration
management were examined with respect to designing essential
components.
Quick Tips
• Including confidentiality, integrity, and availability concepts
in an application
and understanding what the specific requirements are for each
of these elements
help provide an essential foundation for software.
• Authentication needs to be designed into the system, as this
function is a
precursor to other aspects of security functionality.
• Whenever possible, the use of enterprise-level functionality
for security
functions, such as authentication, authorization, and logging,
provide enterprise-
level operational benefits.

• When logging information associated with a failure or error,
care must be taken
to not disclose any sensitive information in logs.
• During the design phase, the attack surface analysis and
threat model provide
information as to the elements that need to be secured in the
application.
• Secure design principles can be employed to assist in the
development of a
comprehensive security solution for an application.
• Design attention should be paid to critical foundational
elements such as
configuration management, exception management, and session
management.
Questions
you with a feel
and then check
of the chapter.
1. The primary source of security information for the design
phase of an
application will be contained in the:
A. Configuration file
B. Threat model

C. Security controls analysis
D. Bug tracking database
2. Designing overlapping mitigations to reduce the chance of
failure is an example
of:
https://learning.oreilly.com/librar y/view/csslp-certification-all-
C. Defense in depth
D. Open design
3. Reusing components to reduce risk is an example of:
A. Leverage existing components
B. Separation of duties
C. Weakest link
D. Least common mechanism
4. The use of standardized design functions for similar or
repeated functionality is
referred to as:

A. Psychological acceptability
C. Open design
D. Economy of mechanism
5. Security management interfaces in an application are best
served by:
A. Logging exception data
B. Integration into existing enterprise security management
systems
C. Exception management systems
D. Separate management interface within the application
6. Out-of-band management interfaces solve which of the
following problems?
A. Require separate communication channel
B. Require less bandwidth
C. Reduce development risks

D. Reduce operational risks
7. Designing a secure communication channel system based on
separate
conversations is referred to as:
A. Configuration management
B. Exception handling
C. Confidentiality-based communications
D. Session management
8. Complete mediation is an approach to security that includes:
A. Design using defense in depth and least privilege
B. A security design that minimizes the opportunity to be
circumvented
C. The design of layered security to provide overlapping
defenses
D. The integration with enterprise security elements of
authentication and
authorization
9. Exception management is involved in the management of:
A. Audit data

B. Confidentiality, integrity, and availability (CIA) data
C. Psychological acceptability
D. Separation of duties
10. Hash functions are commonly employed with respect to:
A. Authorization systems
B. Authentication controls
C. Integrity checking
D. Confidentiality controls
11. Logging of errors and failure information should be
designed to protect:
A. Sensitive information
B. Availability through resilient controls
C. Separation of duties
D. Fail-safe designs
12. Designing a system so all parties can easily understand
design objectives and

maintaining a simple design embrace the principle of?
A. Single point of failure
C. Fail safe
D. Open design
13. The use of legacy code improves development efficiency
through reduced
development time, but still requires:
B. Defense in depth
C. Exception management
D. Complete security testing
14. The security principle of fail safe is related to:
A. Session management
B. Exception management

C. Complete mediation
D. Single point of failure
15. Using the principle of keeping things simple is related to:
A. Defense in depth
C. Economy of mechanism
D. Least privilege
Answers
1. B. The threat model is the primary mechanism to
communicate information
about threats, vulnerabilities, and mitigations in an application.
2. C. Defense in depth is accomplished by the design of
overlapping mitigations.
3. A. Leveraging existing components reduces risk by using

proven elements.
4. D. Reusing components is an example of economy of
mechanism.
5. B. Integration into the enterprise security management
system provides many
operational benefits to an organization through increased
operational
efficiencies.
6. D. Out-of-band management interfaces are less prone to
interference from denial
of service attacks against an application, reducing operational
risk from loss of
management control.
7. D. Session management involves encrypting
communications on a conversation-
by-conversation basis.
8. B. Complete mediation involves the verification of authority
prior to use to avoid
being circumvented.
9. A. Exception management is the management of log or audit
data.
10. C. Hash functions are used to verify integrity.
11. A. When logging information, care should be taken to
prevent the inadvertent
disclosure of sensitive information.
12. D. Open design is all about communicating the design in
clear, simple terms to all

members of the design team.
13. D. Legacy code may not have been developed using an
SDL, so it still requires
complete security testing.
14. B. The principle of fail safe means that when failure
occurs, the system should
remain in a secure state and not disclose information. Exception
management is
the operational tenet associated with fail safe.
15. C. The principle of economy of mechanism means to limit
complexity to make
security manageable, or keep things simple.

CHAPTER 8
Design Processes
• Examine the concept of attack surfaces and attack surface
minimization
• Examine the use of threat modeling to reduce vulnerabilities
• Examine the integration of enterprise security controls to
mitigate threats in
software
• Explore risks associated with code reuse
• Learn how security gate reviews can use threat modeling and
attack surface
information to improve security
Security implementation begins with requirements, and becomes
built in if
designed in as part of the design phase of the secure

development lifecycle (SDL).
Designing in the security requirements enables the coding and
implementation
phases to create a more secure product. Minimization of
vulnerabilities is the
first objective, with the development of layered defenses for
those that remain
being the second objective. To achieve these goals, the software
development
team needs to have a detailed understanding of the specific
threats and
vulnerabilities in the software under development.
Attack Surface Evaluation
The attack surface of software is the code within the system that
can be accessed
by unauthorized parties. This is not just the code itself, but can
also include a
wide range of resources associated with the code, including user
input fields,
protocols, interfaces, resource files, and services. One measure
of the attack
surface is the sheer number or weighted number of accessible
items. Weighting
by severity may change some decision points, but the bottom
line is simple. The
larger the number of elements that can be attacked, the greater
the risk. The
attack surface of software does not represent the quality of the
code—it does not
mean there are flaws; it is merely a measure of how many
features/items are

available for attack.
A long-standing security practice is not to enable functionality
that is not used
or needed. By turning off unnecessary functionality, there is a
smaller attack
surface and there are fewer security risks. Understanding the
attack surface
throughout the development cycle is an important security
function during the
development process. Defining the attack surface and
documenting changes helps
enable better security decision making with respect to
functionality of the
software.
Software is attacked via a series of common mechanisms,
regardless of what
the software is or what it does. Software is attacked all the time,
and in some
remarkably common ways. For instance, weak access control
lists (ACLs) are a
common attack point, and these can be regardless of the
operating system.
Attacks against the operating system can be used against many
applications,
including software that is otherwise secure. Attack surface
evaluation is a means
of measuring and determining the risks associated with the
implications of
design and development.
Attack Surface Measurement
To understand a product’s attack surface, you need to measure
the number of

ways it can be “accessed.” Each software product may be
different, but they will
also share elements. Like many other security items, the first
time a team builds a
list, it will be more difficult. But, over time, the incremental
examination will
detail more items, making future lists easier to develop. In this
light, here is a
published list from Microsoft on attack surface elements
associated with
Windows. Although this list may not be totally applicable, it
does provide a
starting point and acts as a guide of the types of elements
associated with an
attack surface.
• Open sockets
• Open remote procedure call (RPC) endpoints
• Open named pipes
• Services
• Services running by default
• Services running as SYSTEM
• Active web handlers (ASP files, HTR files, and so on)
• Active Internet Server Application Programming Interface
(ISAPI) filters
• Dynamic webpages (ASP and such)

• Executable virtual directories
• Enabled accounts
• Enabled accounts in admin group
• Null sessions to pipes and shares
• Guest account enabled
• Weak ACLs in the file system
• Weak ACLs in the registry
• Weak ACLs on shares
Another source of information is in the history of known
vulnerabilities
associated with previous developments. Determining the root
cause of old
vulnerabilities is good for fixing them and preventing future
occurrences, and it
is also valuable information that can be used in determining the
attack surface.
The list of features that form the attack surface is the same list
that attackers
use to attack a specific piece of software. The items on the list
are not necessarily
vulnerabilities, but they are items that attackers will attempt to
compromise.
These elements are at the base of all vulnerabilities, so while a

particular
vulnerability may or may not exist for a given attack surface
element, there will
be one under each vulnerability that is uncovered. This makes
measuring the
attack surface a solid estimation of the potential vulnerability
surface.
It is important to note that each software product is different,
and hence,
comparing attack surface scores from different products has no
validity. But
counting and measuring the attack surface provides baseline
information from
which security decisions can be made. Different elements may
have different
scoring values, as a service running as a system is riskier than a
nonprivileged
service. Services that are run by default are riskier than those
on the same level
only running on demand.
Attack Surface Minimization
The attack surface is merely a representation of the potential
vulnerability
surface associated with the software. Once a baseline is known,
the next step is to
examine ways that this metric can be lowered. This can be done
by turning off
elements not needed by most users, as this reduces the default
profile surface.
Services that are used can be on or off by default, only on when
needed, run as
system, or without privilege. The lower the privilege, the less a
service is running,

so these factors can reduce the attack surface.
Attack surface minimization is not necessarily an “on or off”
proposition. Some
elements may be off for most users, yet on for specific users
under appropriate
circumstances. This can make certain features usable, yet not
necessarily
exploitable. Reducing the exposure of elements to untrusted
users can improve
the security posture of the code. Minimization is a form of least
privilege, and the
application of it works in the same manner. If the application is
network aware,
restricting access to a set number of endpoints or a restricted IP
range reduces
the surface.
The attack surface should be calculated throughout the
development process.
Work done to reduce the attack surface should be documented
throughout the
process. This will assist in lowering the default surface level at
deployment, but
the information can also be provided to the customer so they
can make informed
decisions as they determine specific deployment options. As
with all changes, the
earlier in the development process a change is made, the lesser
the impact will be
to surrounding elements.
Attack surface minimization should be considered with design
efforts.

Determining the design baseline and listing the elements and
details assist the
development team in achieving these objectives. As the process
continues and
decisions are made that affect the surface, the documentation of
the current
attack surface area helps everyone understand the security
implications of their
specific decisions. Although security may not be easy to
measure directly, the use
of the attack surface as a surrogate has shown solid results
across numerous
firms.
Threat Modeling
Threat modeling is a process used to identify and document all
of the threats to a
system. Part of the description will include the mitigating
actions that resolve the
exposure. This information is communicated across all members
of the
development team, and acts as a living document that is kept
current as the
software progresses through the development process.
Performing threat
modeling from the beginning of the development process helps
highlight the
issues that need to be resolved early in the process, when it is
easier to resolve
them. Threat modeling is an entire team effort, with everyone
having a role in the
complete documentation of the threats and issues associated
with the software.
Threat Model Development

The threat model development process is a team-based process.
The threat model
development occurs across several phases. The first is defining
the security
objectives for the system. Following that is the system
decomposition, then the
threat identification, followed by mitigation analysis. The final
step is the
validation of the model.
Identify Security Objectives
As part of the requirements process, one of the essential
elements is the
determination of the security objectives associated with the
system under
development. These requirements can come from a number of
sources, including
legal, contractual, and corporate standards and objectives. Both
security and
privacy elements can be considered. Documenting an
understanding of the
business rationale for obtaining and storing data; how it will be
used; and the
related laws, regulations, and corporate standards for such
behaviors will assist
in later stages in the understanding of what is required. Leaving
the decision of
what data to protect and how to protect it up to a development
team is a mistake,
as they may not have the breadth or depth of knowledge with
respect to these

requirements to catch all of the possible associated threats.
Laws, regulations,
contractual requirements, and even corporate standards can be
complex and
byzantine, yet if they are to be properly covered, they need to
be enumerated as a
list of requirements for the development effort.
System Decomposition
Once the security objectives are defined for a system, designers
need to ensure
they are covered in the actual design of the system. Numerous
modeling systems
are used in the design of a system. Unified Modeling Language
(UML), use cases,
misuse cases, data flow diagrams (DFDs), and other methods
have been used to
define a system. For the purposes of threat modeling, since the
target is typically
the information being manipulated, the DFD model is the best
choice to use in
documenting the threats.
Beginning in the design phase, as part of a system
decomposition exercise, the
designers can use DFDs to document the flow of data in the
system. When using
DFDs, it is important to identify and include all processes, data
stores, and data
flows between elements. Special attention should be given to
trust boundaries,
where data crosses from one zone of trust to another. In large,
complex systems,
breaking down the DFD into scenario-based pieces may make
documentation

easier. Every assumption and every dependency should be
enumerated and
described. This is the baseline of the document. As the
development process
progresses, any changes to the items in the threat model should
be documented
and updated.
Trust boundaries are key elements, as they represent points
where an attacker
can interject into the system. Inside a trust boundary, items
share the same
privileges, rights, access, and identifiers. Machine boundaries
are obvious trust
boundaries, but inside a system, if privilege changes, this is a
trust boundary, too.
DFD Elements for Threat Modeling
The following are examples of elements to identify as part of
the threat modeling
process:
External Entities
• Users (by type)
• Other systems
Data Stores
• Files
• Database

• Registry
• Shared memory
• Queues/stack
Trust Boundaries
• Users
• File systems
• Process boundaries
Data Flows
• Function calls
• Remote procedure calls (RPCs)
• Network traffic
Threat Identification
Once the system is well documented, then the process of
identifying threats
begins. Threat identification can be done in a variety of
manners, and in most
cases, several methods will be used. An experienced security
person can provide
a series of known threats that are common across applications,
although this list
needs to be tailored to the application under development.

During the DFD
documentation process, as security objectives are documented,
the question of
what issues need to be protected against is answered, and this
information
describes threats. The use of the STRIDE method can be
repeated across
processes, data flows, trust boundaries—anywhere you want to
understand the
security implications of that portion of the application under
development. Using
each of the elements of STRIDE, the threat model is
documented as to what
happens as a result of each element of the STRIDE acronym.
Not every STRIDE
element will warrant documenting at every location, but this
exercise will
uncover many important security considerations.
As the threats are enumerated and documented, try to avoid
becoming
distracted by things that the application cannot control. For
instance, if the
system administrator decides to violate the system (machine)
trust, this is an
operating system issue, not an application issue. Likewise, with
elements such as
“someone steals the hard drive,” other than encrypting essential
data at rest, this
is an outside-the-application issue.
By this point, a lot of data will be associated with the threat
model. There are
tools to assist in the collection and manipulation of the threat
model data, and it
is wise to use an automated tool to manage the documentation.

All of the
described elements up to this point need to be numbered,
categorized, and
managed in some fashion. The next step is an examination of
mitigations that can
be employed to address the threats.
STRIDE
The acronym STRIDE is used to denote the following types of
threats:
Mitigation Analysis
Each threat requires mitigation. Mitigation can be of four types:
redesign to
eliminate vulnerability, apply a standard mitigation, invent a
new mitigation, or
accept the vulnerability. If redesign is an option, and it may be
in the early parts
of the development process, this is the best method, as it
removes the risk. The
next best method is to apply a standard mitigation. Standard
mitigations are
common security functions, such as ACLs, and have several
advantages. First,
they are well understood and are known to be effective. Second,
in many cases,
they will apply across a large number of specific vulnerability
points, making
them an economical choice. Developing new mitigation methods
is riskier and
more costly, as it will require more extensive testing. Accepting

the
vulnerabilities is the least desired solution, but may on occasion
be the only
option.
The threat model is a dynamic document that changes with the
development
effort; so, too, do the mitigations. For a threat that is
documented late in the
development cycle, elements such as redesign may not be
practical for this
release. But the information can still be documented, and on the
next release of
the software, redesign may be an option that improves the
security.
In picking the appropriate mitigation, one needs to understand
the nature of
the threat and how it is manifested upon the system. One tool
that can assist in
this effort is an attack tree model. An attack tree is a graphical
representation of
an attack, beginning with the attack objective as the root node.
From this node, a
hierarchical tree-like structure of necessary conditions is listed.
Figure 8-
1 illustrates a simple attack tree model for an authorization
cookie.

FIGURE 8-1 Attack tree
When describing a threat, it is also useful to gauge the priority
one should
place on it. Some attacks are clearly more serious than others,
and risk
management has dealt with this using probability and impact.
Probability
represents the likelihood that the attack will have success. This
is not necessarily
a numerical probability, but typically is described using
nominal values of high,
medium, and low. Impact represents the loss or risk faced by a
successful attack,
and it, too, is frequently scored as high, medium, or low. To
convert these to a
numerical score, you can apply numbers (high = 3, medium = 2,
low = 1) to each
and multiply the two. The resulting scores will be between 9
and 1. This provides
a means of differentiating threats, with those scoring higher
clearly more
important to address.
Another method is referred to as DREAD, with DREAD being
an acronym for
damage potential, reproducibility, exploitability, affected users,
and
discoverability. To use DREAD, one can assign a value from 0
(nothing), to 5
(moderate), to 10 (severe) for each of the elements. Then the
total risk can be
obtained by summing and dividing by 5, which will yield a
score from 0 to 10.
Another method is to set discoverability to 10, assuming
discovery when doing

the analysis. DREAD can be mapped into the probability impact
model by taking
the following factors into account: probability (reproducibility
+ exploitability +
discoverability) and impact (damage potential + affected users).
Threat Model Validation
As the software development process moves through the phases
of the SDL, at
gates between the phases, an opportunity to examine materials
presents itself.
The current version of the threat model should be validated at
each of these
opportunities. The purpose of the validation phase is to assess
the quality of the
threats and mitigations. For the threats, it is important to ensure
that they
describe the attack and the impact in detail relevant to the
context of the
application. For mitigations, it is important that they are
associated with a threat
and are completely described in terms relevant to the context of
the application.
Any and all dependencies should be documented. Documenting
both what
other code bases you are relying on and the security functions
associated with
that code is important. Ensuring all dependencies are
documented is important at
each phase of the SDL. Any assumptions that are made as part
of the

development process are also important to document.
Control Identification and Prioritization
Security controls are the primary mechanisms that enterprises
use to manage
security. These controls form the backbone of the enterprise
security function
and can be applied as part of the mitigation package for the
application under
development. Using enterprise controls such as ACLs
implements security
mitigations and does so in a manner where the enterprise can
operationally
perform the tasks efficiently and correctly.
Priority should be afforded to any security control that exis ts in
the enterprise.
Although some applications may have the ability to maintain
their own access
control mechanism, managing the security of the user base adds
duplicative
work. Aligning the access control, user authentication, and
other security
mechanisms to those employed in the enterprise reduces the
operational security
workload and still achieves the desired mitigating actions.
Software programs and applications do not exist in a vacuum.
Part of the
Microsoft SDL process is to have systems be secure by design,
by default, and in
deployment. Using design elements to ensure integration into

appropriate
enterprise security controls assists in these objectives. Use of
security provisions
of existing protocols, such as IPSec, Hypertext Transfer
Protocol Secure (HTTPS),
Secure Shell (SSH), and others, can provide significant security
mitigation efforts
that are supported by the platform and the enterprise and are
optimally
managed. Reducing any duplication of security functionality
reduces
development risks and improves deployment and operations of
the software.
Risk Assessment for Code Reuse
Code reuse has been a practice in the software development
industry since its
beginning. The reasons are many: saving time, reducing work,
and providing
consistency. Software libraries are the ultimate example of code
reuse. However,
code reuse does not come without risk. Reuse of older code has
resulted in errors
in the past and will do so again in the future. Legacy code from
products as old as
Windows for Workgroups has resulted in security issues in
products up to
Windows XP.
When old code is reused in a project, it should be subjected to
the same
scrutiny as the new code under development. Old code should
be included in
threat modeling and attack surface minimization efforts. Code
reviews and

walkthroughs can provide valuable insight into risks associated
with legacy code.
Vulnerabilities that did not exist in the code at the time it was
developed can
arise due to changes in the environment that the code operates
in. Examining the
code in the context of the current operating environment can
reveal issues that
would not have been discoverable in the original environment.
Documentation
The documentation associated with threat modeling and attack
surface
minimization provides a wealth of security-related information.
Keeping this
documentation up to date is not just a paperwork exercise to
satisfy an auditor or
regulation, but provides value as a roadmap and encyclopedic
repository for
team use.
The purpose of the documentation is to communicate essential
information
across the development team. Beginning with requirements and
progressing all
the way through the development process, the information
compiled in the
documentation provides a guide to keep all team members on
the same plane
throughout. As each new phase of the development process is
started, the
documentation provides a running narrative of the security

issues that have been
identified, the plans to mitigate, and the expectations of the
development process
with regard to achieving these objectives. As the attack surface
area is always a
dynamic issue, each phase should monitor this issue and keep
the plan updated
with current options and measurements. Making this an issue
that is tracked
helps draw attention to subtle creep that increases this risk
without a full
understanding of the causes and ramifications.
In this same vein, the threat model documentation provides a
wealth of
detailed information concerning security objectives, an
enumeration of threats,
how vulnerabilities and mitigations are being handled, and
documentation on
dependencies and assumptions. This information can be used by
the software
development team to ensure that issues are not overlooked or
that design
elements are not providing the best platform options for
minimizing security
risk. As with other aspects of the security documentation, the
living nature of the
threat model portion is, by design, encouraging improvement of
the threat model
at every step of the development process. Keeping the team
aware of and focused
on what can be done to mitigate the specific vulnerabilities
enables the entire
team to assist in creating the most secure implementation
possible.

Design and Architecture Technical Review
Using the results of the documentation from the attack surface
area and the
threat model enables the development team to properly design
and implement
security functionality in the application under development.
Periodic reviews of
the development progress should include reviews of the security
progress as well.
Code walkthroughs, design reviews, examination of the attack
surface area, and
threat modeling documentation with an eye toward
completeness are key
elements of these reviews.
The periodic reviews are not just technical to ensure that the
products of the
SDL process are technically complete and accurate, but are also
process focused.
Equally important is the notion that the SDL process is
functioning as planned to
achieve the desired objectives. The security review process is
really a two-
pronged effort. The primary effort needs to be done by the
development team
during each phase of the development process. Security cannot
be added in after
the fact by the security team, but instead must be baked into the
product as part
of the development effort. The attack surface minimization and
threat modeling
efforts provide a process-wide vehicle for managing these

issues and building
security into the application. The SDL process is designed to
specifically support
this effort. As part of the review efforts at every level, ensuring
that proper
attention is being devoted to the security posture is the entire
team’s
responsibility. The primary function of the security review at
the process gates is
to ensure that this activity is occurring and performing at the
desired levels.
Thus, the security review is oriented to the process, not just to
ensuring that all of
the security bases are being covered.
Chapter Review
This chapter opened with an examination of attack surfaces and
how they play a
role in security software. The chapter continued the coverage of
attack surfaces,
examining how they are defined, measured, and ultimately
minimized. This
information is documented in a report that is updated
throughout the
development process. Threat modeling was presented as the tool
and mechanism
used to understand and mitigate the threats against the
application. A detailed
examination of how threat modeling is performed, what is
documented, and how
the information is used to reduce vulnerabilities was presented.
The integration
of threat modeling continued with a discussion of the risks
associated with code
reuse and an examination of how security controls are used to

improve security
in the product.
The chapter concluded with an examination of how the
documentation from
the attack surface and threat modeling efforts can be used to
achieve team
coordination in the pursuit of application security objectives.
Quick Tips
• The attack surface of an application represents a measure of
how many
features/items are available for attack.
• The actual measure of an attack surface is useful across the
development process
to measure improvement on numbers of potential
vulnerabilities.
• Threat modeling is a process used to identify and document
all of the threats to a
system.
• Threat modeling has five phases: define security objectives,
system
decomposition, threat enumeration, mitigation analysis, and
validation of the
model.
• STRIDE represents spoofing, tampering, repudiation,
information disclosure,
denial of service, and elevation of privilege.

• Attack trees provide causal information with respect to
attack vectors.
• DREAD represents damage potential, reproducibility,
exploitability, affected
users, and discoverability.
• When securing vulnerabilities, priority should be afforded to
any security control
that exists in the enterprise.
• Attack surface and threat modeling documentation are living
documents to
communicate security information across the development team.
Questions
you with a feel
and then check
of the chapter.
1. The increasing value for the attack surface of an application
during development
is indicative of:
A. Excess risk
B. Declining code quality
C. An increase in addressable resources
D. An improvement in security

2. You have moved to a new project, and the attack surface
measurement indicates
an attack surface only half of the value of the project you just
left. This indicates:
A. More work on minimization is needed.
B. The previous project was more secure from a security
perspective.
C. The previous project was twice as big; no problem.
D. Nothing. Attack surface measurements are not comparable
across different
projects.
3. The attack surface of your project seems to grow faster than
it should. Which of
the following is probably not a fruitful place to look?
A. Number of modules/routines in the project
B. Privilege level of the credentials used to run the application
C. Network address space from which the program is
addressable
D. Privilege level of users using the application
4. The first step in threat modeling is:

A. Define security objectives for the application.
B. Pick a threat model team.
C. Decompose the application into smaller pieces.
D. Measure the attack surface of the application.
5. STRIDE stands for:
A. Spoofing, trust violation, repudiation, information
B. Spoofing, tampering, repudiation, information disclosure,
denial of service,
C. Spoofing, tampering, reproducibility, information
D. Spoofing, tampering, repudiation, information disclosure,
denial of service,
exploitability
6. DREAD stands for:

A. Damage potential, reproducibility, exploitability, affected
B. Damage potential, repudiation, exploitability, affected
C. Damage potential, reproducibility, exploitability, asset
value, discoverability
D. Damage potential, reproducibility, elevation of privilege,
affected users,
discoverability
7. Inside a trust boundary, items:
A. Share the same ACL access
B. Share the same privileges, rights, access, and identifiers
C. Share the same user account
D. Are not observable
8. A threat model is validated for all of the following except:
A. Appropriate mitigations are assigned to all threats listed.
B. All security threats are identified.
C. Dependencies have been considered and are documented.
D. The quality of mitigations is adequate.

9. To reduce the risk associated with reusing code, the
development team should:
A. Never reuse code, but develop all code via the SDL process
B. Identify and document the risk of reused code
C. Perform testing and validation on reused code in the same
fashion as new code
D. Only use code certified for the project
10. If there is not sufficient time to finish the threat model
documentation, the team
should:
A. Request a waiver from the security team
B. Push the documentation into the next phase as an item to be
finished
C. Delay the gate until the documentation is complete
D. Don’t worry about the documentation if the work is done
correctly
11. The primary purpose behind security reviews is to:
A. Ensure that all steps of the SDL are being properly
followed

B. Ensure that the attack surface model is updated at each
phase
C. Assess the quality of security actions, including mitigations
for vulnerabilities
D. Ensure that the threat model is updated at each phase
12. The STRIDE model is applied to:
A. Attack surfaces in the attack surface model
B. Threat identification efforts as part of threat modeling
C. Determine the risk from a threat
D. Every threat found during the attack surface area
measurement effort
13. The best method of system decomposition for threat
modeling is the construction
of:
A. Misuse cases

B. Use cases
C. UML
D. DFDs
14. Which of the following is not a mitigation method for
threats identified in threat
modeling?
A. Redesign to eliminate vulnerability.
B. Apply a standard mitigation.
C. Change the security requirements to eliminate the threat.
D. Accept the vulnerability.
15. The preferred security mitigation to use during threat
modeling is:
A. A custom control created specifically for the threat
B. Encryption from an approved library to prevent information
disclosure
C. Acceptance of the vulnerability
D. Standard enterprise-level security controls in common use,
such as ACLs
Answers

1. C. An increase in the value of the attack surface indicates
an increase in the
number of addressable resources.
2. D. Attack surface measurements are defined by the breadth
and scope of
addressable elements, and thus are not strictly comparable
across different
projects.
3. A. The number of modules a program is composed of does
not factor directly into
attack surface calculations.
4. A. Defining the security objectives for an application forms
the foundation for all
threat modeling efforts.
5. B. STRIDE is an acronym for spoofing, tampering,
repudiation, information
disclosure, denial of service, and elevation of privilege.
6. A. DREAD is an acronym for damage potential,
reproducibility, exploitability,
affected users, and discoverability.
7. B. This is the definition of a trust boundary; inside a trust
boundary, items share
the same privileges, rights, access, and identifiers.
8. B. It is never possible to identify all threats to a s ystem.

9. C. Legacy code can be included in new projects, but it
should be subjected to all
of the same security steps and tests as new code.
10. C. The security review should block advancement under
the SDL process until all
aspects of a phase are complete and properly done.
11. A. The primary purpose of security reviews is to assess the
efficacy of the SDL,
with that efficacy having the desired security effects, not the
review itself.
12. B. STRIDE is used during the threat identification phase to
identify types of
threats.
13. D. Data flow diagrams are best suited for the identification
of threats to a system.

14. C. Changing the security requirements does not eliminate a
threat; it merely
results in it being ignored.
15. D. The preferred set of mitigations are enterprise-level
security controls already
in place and used in the enterprise.
Software Assurance Maturity Model
http://www.opensamm.org

AgendaReview of existing secure SDLC effortsUnderstanding
the modelApplying the modelExploring the model’s levels and
activitiesSAMM and the real world
By the end, you’ll be able to...Evaluate an organization’s
existing software security practicesBuild a balanced softwar e
security assurance program in well-defined
iterationsDemonstrate concrete improvements to a security
assurance programDefine and measure security-related activities
throughout an organization
Review of existing secure SDLC efforts
CLASPComprehensive, Lightweight Application Security
ProcessCentered around 7 AppSec Best PracticesCover the
entire software lifecycle (not just development)Adaptable to any
development processDefines roles across the SDLC24 role-
based process componentsStart small and dial-in to your needs
Microsoft SDLBuilt internally for MS softwareExtended and
made public for othersMS-only versions since public release
TouchpointsGary McGraw’s and Cigital’s model

Lessons LearnedMicrosoft SDLHeavyweight, good for large
ISVsTouchpointsHigh-level, not enough details to execute
againstCLASPLarge collection of activities, but no priority
orderingALL: Good for experts to use as a guide, but hard for
non-security folks to use off the shelf
Drivers for a Maturity ModelAn organization’s behavior
changes slowly over timeChanges must be iterative while
working toward long-term goalsThere is no single recipe that
works for all organizationsA solution must enable risk-based
choices tailor to the organizationGuidance related to security
activities must be prescriptiveA solution must provide enough
details for non-security-peopleOverall, must be simple, well-
defined, and measurable
Therefore, a viable model must...Define building blocks for an
assurance programDelineate all functions within an organization
that could be improved over timeDefine how building blocks
should be combinedMake creating change in iterations a no-
brainerDefine details for each building block clearlyClarify the
security-relevant parts in a widely applicable way (for any org
doing software dev)
Understanding the model
SAMM Business FunctionsStart with the core activities tied to
any organization performing software developmentNamed

generically, but should resonate with any developer or manager
SAMM Security PracticesFrom each of the Business Functions,
3 Security Practices are definedThe Security Practices cover all
areas relevant to software security assuranceEach one is a ‘silo’
for improvement
Under each Security PracticeThree successive Objectives under
each Practice define how it can be improved over timeThis
establishes a notion of a Level at which an organization fulfills
a given PracticeThe three Levels for a Practice generally
correspond to:(0: Implicit starting point with the Practice
unfulfilled)1: Initial understanding and ad hoc provision of the
Practice2: Increase efficiency and/or effectiveness of the
Practice3: Comprehensive mastery of the Practice at scale
Check out this one...
Per Level, SAMM defines...ObjectiveActivitiesResultsSuccess
MetricsCostsPersonnelRelated Levels
Approach to iterative improvementSince the twelve Practices
are each a maturity area, the successive Objectives represent the
“building blocks” for any assurance program
Simply put, improve an assurance program in phases by:

Select security Practices to improve in next phase of assurance
program
Achieve the next Objective in each Practice by performing the
corresponding Activities at the specified Success Metrics
Applying the model
Conducting assessmentsSAMM includes assessment worksheets
for each Security Practice
Assessment processSupports both lightweight and detailed
assessmentsOrganizations may fall in between levels (+)
Creating ScorecardsGap analysisCapturing scores from detailed
assessments versus expected performance levels Demonstrating
improvementCapturing scores from before and after an iteration
of assurance program build-out Ongoing measurementCapturing
scores over consistent time frames for an assurance program
that is already in place
Roadmap templatesTo make the “building blocks” usable,
SAMM defines Roadmaps templates for typical kinds of
organizationsIndependent Software VendorsOnline Service
ProvidersFinancial Services OrganizationsGovernment
OrganizationsOrganization types chosen becauseThey represent
common use-casesEach organization has variations in typical

software-induced riskOptimal creation of an assurance program
is different for each
Building Assurance Programs
Case StudiesA full walkthrough with prose explanations of
decision-making as an organization improvesEach Phase
described in detailOrganizational constraintsBuild/buy
choicesOne case study exists today, several more in progress
using industry partners
Exploring the model’s levels and activities
The SAMM 1.0 release
SAMM and the real world
SAMM historyBeta released August 20081.0 released March
2009Originally funded by FortifyStill actively involved and
using this modelReleased under a Creative Commons
Attribution Share-Alike licenseDonated to OWASP and is
currently an OWASP project

The OpenSAMM Projecthttp://www.opensamm.orgDedicated to
defining, improving, and testing the SAMM frameworkAlways
vendor-neutral, but lots of industry participationOpen and
community drivenTargeting new releases every 6-12
monthsChange management processSAMM Enhancement
Proposals (SEP)
Future plansMappings to existing standards and regulations
(many underway currently)PCI, COBIT, ISO-17799/27002,
ISM3, etc.Additional roadmaps where need is
identifiedAdditional case studiesFeedback for refinement of the
modelTranslations into other languages
Other “modern” approachsMicrosoft SDL Optimization
ModelFortify/Cigital Building Security In Maturity Model
(BSIMM)
SDL Optimization ModelBuilt by MS to make SDL adoption
easier
BSIMMFramework derived from SAMM BetaBased on collected
data from 9 large firms
Quick re-cap on using SAMMEvaluate an organization’s

existing software security practicesBuild a balanced software
security assurance program in well-defined
iterationsDemonstrate concrete improvements to a security
assurance programDefine and measure security-related activities
throughout an organization
ISEC 620 Lab 3: Threat ModelingIntroduction
In the previous lab, you created a Kanban Board. One of the
tasks you created in Module-2 should be to perform threat
modeling for the blog website you have been developing for
your customer. You decided to perform threat modeling after
the vulnerability management team discovered a critical
vulnerability on the web service.
The blog site is in the staging environment. It will be migrated
to the production environment in the Azure cloud next month.
The blog site will eventually serve as an information sharing
and collaboration portal for authenticated users. It will use an
SQL database at the backend.
As the project manager, you want to see the Data Flow Diagram
(DFD) that shows the communications between various entities
and to perform threat modeling with your team to explore
threats and suggest countermeasures.Resources
Please read the following articles:
A short introduction to Microsoft's STRIDE (Spoofing,
Tampering, Repudiation, Information Disclosure, Denial of
Service, and Elevation of Privilege) threat modeling approach:
https://www.microsoft.com/en-
us/securityengineering/sdl/threatmodeling
A short case:
https://docs.microsoft.com/en-us/azure/security/develop/threat-
modeling-tool-getting-started
A detailed case, learn more about the approach to threat
modeling in this article:
https://docs.microsoft.com/en-us/archive/msdn-
magazine/2006/november/uncover-security-design-flaws-using-
the-stride-approach
You will use Microsoft Threat Modeling Tool in this lab.

Familiarize yourself with the tool by reviewing this page:
https://docs.microsoft.com/en-us/azure/security/develop/threat-
modeling-tool-feature-overviewLab Environment
Access to Microsoft Threat Modeling Tool:
1) If you want to run it on your Windows machine, you can
download it from https://aka.ms/threatmodelingtool and run the
tool on your personal computer.
2) Alternatively, you can reserve the Windows 10 instance in
the Netlab environment (https://netlab.franklin.edu). Please
refer to the Netlab Reservation Instructions for access details.
Instructions & Questions
1. Double click the Microsoft Threat Modeling 2016 icon on the
desktop.
2. Click the Browse button and select the Azure Cloud Services
file.
3. Click the Create A Model.
4. Please refer to the "Microsoft Threat Modeling Tool 2016
Guidance" section of this document to get guidance on using the
threat modeler tool.
Part 1: Create a Data Flow Diagram
There is no single solution for this lab. After carefully reading
the description given in the introduction section of this lab
instruction, draw a DFD that shows Data stores, Processes,
Interactors, Data flows, and Trust boundaries. Take the
screenshot of the DFD.
Part 2: Review Threats
1. Switch to analysis view
2. Review all of the threats that are automatically devised by
the tool
3. Add two more threats.
Take a screenshot of the new threats.
Part 3: Devise Mitigations and Change Threat Properties
1. For the threats you added, change the status to Mitigated and

fill out the "Possible Mitigations" section.
2. Choose one threat, change the status to "Not Applicable". Fill
out the justification section.
3. Choose another threat, change the status to "Need
Investigation". Adjust the severity level and write a justification
for it.
Take the screenshots that show the result of your actions.
Part 4: Reporting
1. Click the Reports menu and "Create Full Report".
2. Review the downloaded report.
Part 5: Project Management
1. Log into your Azure Board and create a task for the threat
that needs investigation.
2. Take the screenshot of the Azure board showing the tasks.
Submit the Full Report and screenshots.
Microsoft Threat Modeling Tool 2016 Guidance
The below figure shows how to switch to analysis view.
In the analysis view, you see some generic threats, as shown
below.
Right-click on the objects you created (Sample objects:
“Request”, “Response,” and Trust Boundaries). You will see the
"Add User-defined Threat" option.
Once you click on "Add User-defined Threat", the threat list
will show the new threat (1).
Fill out the details of the new threat (2).
Name: ISEC 620 Homework 3

Please review the chapters about attack trees and attack
libraries:
Attack Trees:
https://learning.oreilly.com/library/view/threat-modeling-
designing/9781118810057/9781118810057c04.xhtml#c04_level
1_1
Attack Libraries (CAPEC and OWASP Top Ten attack
libraries):
https://learning.oreilly.com/library/view/threat-modeling-
designing/9781118810057/9781118810057c05.xhtml
Attack trees are an essential method for threat assessment. It
evaluates the security of a system from an attacker perspective.
The root node represents the attacks' goal, and the remaining
leaves indicate sub-goals or attack methods.
In this homework, you are expected to provide an attack tree for
the system you threat-modeled in the lab. The goal of the
attacks is to steal information from the password-protected blog
website. Question 1
Provide a report that includes your analysis. The report should
consist of (but not limited to) the following items:
1. Initial attack interfaces and a short description of why they
can be the starting point for attacks
2. Attack tree
a. Sub-goals
b. The nodes of the tree (Please use AND, OR functions
appropriately)Question 2
Map the sub-goals and attack methods with the attack libraries
given in the second reading Question 3 - Weekly Learning and
Reflection
In two to three paragraphs of prose (i.e., sentences, not bullet
lists) using APA style citations if needed, summarize and
interact with the content that was covered this week in class. In
your summary, you should highlight the major topics, theories,
practices, and knowledge that were covered. Your summary
should also interact with the material through personal
observations, reflections, and applications to the field of study.

In particular, highlight what surprised, enlightened, or
otherwise engaged you. Make sure to include at least one thing
that you’re still confused about or ask a question about the
content or the field. In other words, you should think and write
critically not just about what was presented but also what you
have learned through the session. Questions asked here w ill be
summarized and answered anonymously in the next class.

CHAPTER 9 Design Considerations In this chapter you will

More Related Content

Similar to CHAPTER 9 Design Considerations In this chapter you will (20)

More from JinElias52 (20)

Recently uploaded (20)

CHAPTER 9 Design Considerations In this chapter you will