Figure 4.4 Example data flow diagram for application threat modeling.
User/WebServerBoundary
Data
Corporate
Website
CorporateMarketing
ProductSheets
Database
Database
Files
WebPages
onDisk
SQL Query Calls
SQL
Query
Calls
User/Web Server Boundary
Request
Request
Response
RemoteEmployees
Customers
User/Web
Server
Boundary
Response
Customer/ServiceProviderTrustBoundary
Data
*aaS Service
[CloudServices]
CloudOperations/
SaaS Operations
CustomerData
AccesstoService
throughWeb,APIs
andApps
Response/Request
Response
Response/Request
Re
q
uest
Response
Customer/ServiceProviderTrustBoundary
Customers
q
Figure 4.5 Example data flow diagram for a cloud-based application.
Architecture (A2): SDL Activities and Best Practices 93
• Tiered structure that should be part of Web applications is not
developed fully (or at least not part of this DFD). This might sim-
plify the diagram but may also hide some use cases and flows.
The DFD in Figure 4.5 is an example of *aaS based services provided
to customers. Instead of a traditional Web application, this DFD shows
an example of how customers access services through a cloud provider.
The most obvious security control in this case is protecting customer
data through cloud operations. Customers can access service in multi-
ple ways—through API calls, Web applications, or custom application
development.
Examining the flow diagram more closely, we notice the following:
• There is no distinction between application access through an API
or the Web.
• Cloud operations is a high-level abstraction for more detailed cloud
operations architecture.
• The DFD does not tell us anything about segmentation between
different customers.
• It also does not show how secure the data is—i.e., is it encrypted, are
Web servers talking only to database servers in a cluster or is com-
munication any-any?
Getting the DFD right is key to getting the threat model right. Spend
enough time on yours, making sure all the pieces of your system are repre-
sented. Each of the elements (processes, data stores, data flows, and inter-
actors) has a set of threats to which it is susceptible, as you can see in
Figure 4.6. This chart, along with your DFD, gives you a framework for
investigating how your system might fail.
5
The DFD process requires not only that you think like an attacker
but possibly like multiple attackers, particularly if your software pro-
duct is going to be operating in the could or a SaaS environment. Once
the DFD is completed, you should have an accurate overview of the
how data is processed by the software, including how it moves and what
happens to it within the application and others that may be associated
with it. The high levels of the DFD clarify the scope of the applica-
tion, and the lower levels clarify processes involved when specific data
is being processed.
DataFlow DataStore Process External
Spoofing
3 3
Tampering
3 3
Repudiate
3
*
3 3
Info
rmation
3
3
3
Info
rmation
Disclosure
3
3
3
Denialof
Service
3 3 3
El
3
El
evate
Privilege
3
Figure 4.6 Threats affecting elements. (*For data stores that are logs, there is concern about repudiation issues, and
attacks on the data store to delete the logs. A set of questions to make these threats more concrete and accessible should
be used to make this assessment more complete.
35
)
Architecture (A2): SDL Activities and Best Practices 95
4.3.3 Architectural Threat Analysis
and Ranking of Threats
4.3.3.1 Threat Determination
The first step in determining threats is to adopt a methodology by which
you can categorize them. This provides the ability to systematically iden-
tify sets of threat categories within the software application in a structured
and repeatable manner. STRIDE is a method of threat categorization that
was popularized by Microsoft a number of years ago and will be used
in this chapter as an example of a threat determination tool, but it is
certainly not the only methodology that can be used. Each letter in the
acronym STRIDE helps classify attacker goals:
• Spoofing
• Tampering
• Repudiation
• Information disclosure
• Denial of service
• Elevation of privilege
6
The first step in STRIDE is to decompose your system into relevant
components, then analyze each component for susceptibility to the
threats, and finally, mitigate the threats. The process is then repeated
until you are comfortable with any remaining threats. The system is then
considered secure, since you have now broken your software application
and system down to individual components and mitigated the threats
to each. Of course, this methodology has its flaws in that the individual
components of the software and system can be part of a larger system and
you are only as secure as your weakest link. Individual components of a
software product and system may not be susceptible to a threat in isola-
tion but may be once it is part of a larger system. This is particularly true
for software products that were not designed to be used on the Internet,
in the cloud or SaaS environment.
General threats and the security controls they may affect within each
of the STRIDE categories include the following:
• Spoofing: A threat action that is designed to illegally access
and use another user’s credentials, such as username and
password—Authentication
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.