2 CONTINUOUS ASSURANCE USING DATA THREAT MODELING

CONTENTS
4 Introduction
​4 ​ /​Goal:​​Adopt​an​Attacker’s​View
5 The Current State
​5 ​ /​Practical​Challenges
​6 ​ /​Regulatory​Requirements
7 Data Threat Modeling
​7 ​ /​Identify​Subcomponents,
Dependencies​and​Interaction​Points
​8 ​ /​Discover,​Inventory​and​Evaluate
Threats
​9 ​ /​Mitigate​the​Risk​Brought​About​by
Threats
9 Extending to Data Life Cycle
Management
​9 ​ /​Scope​Definition
​1 0​ /​Mapping
​1 1​ /​Extension​of​Analysis
​1 1​ /​Adaptation​for​the​Supply​Chain
​1 2​ /​Implementation​Guidance
13 Continuous Assurance
13 Specific Goals
​1 4​ /​Putting​Into​Practice:​​Questions​to
Evaluate
15 Conclusion
16 Acknowledgments

© 2018 ISACA. All Rights Reserved.

3 CONTINUOUS ASSURANCE USING DATA THREAT MODELING

ABSTRACT
Data​are​an​extremely​important​commodity​for​enterprises.​They​are​a​factor​in
enterprise​competitiveness,​in​regulatory​considerations,​and​they​are​reflected​in
capability​planning,​for​example,​maturity​and​resiliency.​In​addition,​data​are​a​key
consideration​in​how​enterprises​monitor​and​manage​their​risk​over​time.​Some​changes
that​happen​over​time—for​example,​changes​in​context,​environmental​factors​or​the
threat​landscape—impact​the​level​of​risk​to​which​data​are​subject.​These​changes
should​be​monitored​and​evaluated​to​continuously​assure​that​the​risk​is​kept​within
parameters​that​are​acceptable​to​management.

The​challenge​is​to​move​the​process​of​accounting​for​data​in​a​structured,​systematic
way​higher​on​the​list​of​an​enterprise’s​priorities.​One​option​to​accomplish​this​challenge
is​by​applying​application​threat​modeling​principles​to​data​(“data​threat​modeling”).
Application​threat​modeling​provides​value​by​allowing​application​security​specialists​to
systematically​evaluate​an​application​from​an​attacker’s​viewpoint.​By​doing​this,​an
analyst​can​methodically​analyze​an​application​to​identify​and​map​the​threats​that​the
application​is​likely​to​encounter​in​post-deployment​conditions.​This,​in​turn,​allows
application​specialists​to​establish​mechanisms​to​address​those​threats​and​to​monitor
conditions​that​can​impact​the​application​over​time.

By​looking​at​data​in​this​way​and​following​a​formalized​methodology,​enterprises​can
establish​a​model—and​baseline—for​monitoring​their​ongoing​data​risk​over​time.​By
having​a​model​and​baseline,​enterprises​can​understand​the​risk​in​context,​allowing
them​to​better​track​changes​in​data​that​impact​risk.​Likewise,​this​type​of​approach
helps​to​develop​increasing​focus​on​problem​areas​with​respect​to​data.

© 2018 ISACA. All Rights Reserved.

4 CONTINUOUS ASSURANCE USING DATA THREAT MODELING

Introduction
If​security,​risk,​governance​or​assurance​practitioners​are • ​How the data are used—New​business​processes,​better​analytics​and

asked​to​name​the​most​important​consideration​for​their any​change​in​how​the​data​are​understood​and​processed

enterprises,​there​is​a​strong​likelihood​they​will​answer • ​How data are protected—New​controls/countermeasures,​changes​in

“the​data.”​Data​are​the​lifeblood​of​modern​enterprises. the​operation/effectiveness/performance​of​existing​controls​and

They​are​a​factor​in​enterprise​competitiveness—data removal​of​controls

directly​support​better​engagement​with​customers​and • ​Threats to which data are likely to be exposed—New​threats,​changes

pursuit​of​new​markets;​they​are​a​factor​in​regulatory to​existing​threats,​etc.

considerations,​such​as​governance,​security​and​privacy • ​Business activities—New​or​modified​business​activities​that,​although

regulation;​and​they​are​reflected​in​capability​planning,​for they​do​not​change​how​data​are​used,​change​the​significance​or

example,​maturity​and​resiliency.​In​fact,​data​are​a​factor impact​if​a​compromise​or​other​undesired​event​occurs

in​almost​anything​of​significance​that​an​enterprise​seeks Not​only​is​it​important​to​consider​data​as​defense
to​accomplish. strategies​are​rolled​out​today—and​put​measures​in​place
to​address​specific​risk​at​this​point—but​it​is​also
Although​it​is​a​truism​that​data​are​critical,​they​are
important​to​become​proactive​in​how​that​risk​is
critical​in​a​few​very​specific​ways.​First,​they​are​critical
monitored,​measured​and​evaluated​over​time.​This​is
as​a​key​consideration​in​how​professionals​assess​and
important​because​all​factors​previously​discussed​can
evaluate​the​controls​they​deploy​to​keep​their​enterprises
impact​an​enterprise’s​risk​equation​(potentially​requiring​it
protected.​From​an​end-user​point​of​view,​one​needs​only
to​implement​new​controls​to​keep​risk​within​defined
to​look​at​the​headlines​to​see​the​many​negative
thresholds),​cause​the​enterprise​to​question​or​re-
consequences​that​can​occur​as​a​result​of​a​data​breach.
evaluate​business​decisions,​or​impact​how​the​enterprise
Second,​from​an​attacker’s​point​of​view,​data​can​be
does​things​in​a​myriad​of​different​ways.
rapidly​converted​into​profit,​for​example,​by​selling​stolen
data​or​gating​access​to​the​data​via​ransomware.
Therefore,​data​should​be​considered​and​analyzed​as Goal: Adopt an Attacker’s View
professionals​select,​plan​and​deploy​controls,​and​should
Although​it​is​fairly​easy​to​understand​why​it​is​valuable
also​be​part​of​enterprise​evaluation​of​the​performance
to​adopt​an​attacker’s​view,​enterprises​want​to​know​how
of​those​controls,​relative​to​risk​that​impacts​the​data.
to​realize​that​vision.​One​way​is​to​take​an​“attacker’s-eye
While​those​considerations​are​important,​there​are view”​of​the​data,​that​is,​looking​at​the​data​the​same​way
additional​dimensions​to​how​data​play​a​role​in​the an​attacker​does:​​as​a​target​to​acquire​that​is​accessible
security​posture​and​risk​management​profile​of​the through​a​number​of​potential​pathways.​A​formalized
enterprise​as​a​whole.​For​example,​data​are​a​key threat​modeling​exercise​can​accomplish​this​by​using​a
consideration​in​how​enterprises​monitor​and​manage methodology​that​is​similar​to​the​method​used​by
their​risk​over​time.​Changes​in​context,​environmental application​security​specialists​to​systematically​evaluate
factors​or​the​threat​landscape​may​impact​the​level​of an​application​from​an​attacker’s​point​of​view.
risk​to​which​data​are​subject.​These​changes​should​be
Application​threat​modeling​is​a​discipline​that​has
monitored​and​evaluated​to​continuously​assure​that​the
developed​as​an​application​security​strategy​that​is​in
risk​is​kept​within​parameters​that​are​acceptable​to
fairly​broad​use​within​enterprises​that​want​to​ensure​that
management.​Examples​of​changes​that​should​be
the​applications​they​develop​and​field​are​robust,​resilient
monitored​include:

© 2018 ISACA. All Rights Reserved.

 5 CONTINUOUS ASSURANCE USING DATA THREAT MODELING
and​hardened​against​attack.​Application​threat​modeling
provides​value​by​allowing​application​security​specialists
to​systematically​evaluate​an​application​from​an
attacker’s​viewpoint.​By​doing​this,​an​analyst​can
methodically​analyze​an​application​to​identify​and​map
the​threats​that​the​application​is​likely​to​encounter​in
post-deployment​conditions.​This,​in​turn,​allows
application​specialists​to​establish​mechanisms​to
address​those​threats​and​to​monitor​conditions​that​can
impact​the​application​over​time.
By​looking​at​data​in​this​way​and​following​a​formalized
methodology,​enterprises​can​establish​a​model—and
baseline—for​monitoring​their​ongoing​data​risk​over​time.
By​having​a​model​and​baseline,​enterprises​can
understand​the​risk​in​context,​allowing​them​to​better
track​changes​in​data​that​impact​risk.​Likewise,​this​type
of​approach​helps​to​develop​increasing​focus​on​problem
areas​with​respect​to​data.​One​such​problem​area​is​data
that​intersect​with​the​supply​chain—for​example,​data
that​are​held​in​trust​by​a​service​provider​or​that​are
shared​with​business​partners​or​customers.​Adopting​an
attacker’s​point​of​view​helps​to​highlight​potential​areas
of​concern​in​the​supply​chain​and​can​help​to​focus
resources​on​areas​that​need​it​most.
Enterprises​can​also​use​the​information​gained​from​this
The Current State
Before​doing​that,​though,​it​is​useful​to​understand
existing​conditions​in​the​field​as​they​pertain​to​data.
Specifically,​there​are​two​parallel​transformations
happening​that,​taken​together,​make​data​a​particularly
thorny​problem​to​address​for​enterprises.​The​first
transformation​relates​to​practical​challenges​in​data
management​as​the​data​proliferate—the​engineering​and
management​challenges​that​arise​as​enterprises​make
better​use​of​data,​collect​more​data,​and​change​how
they​consume​and​share​data.​The​second​transformation
1
1
SecurityScorecard,​“Scoring​Methodology,”​August​2017,​https://explore.securityscorecard.com/rs/797-BFK-857/images/Scoring%20Methodology.pdf
© 2018 ISACA. All Rights Reserved.
model​to​understand​contextual​factors​that​apply​to​data
based​on​where​they​are​stored,​processed​or​transmitted.
ISACA​has​partnered​with​SecurityScorecard​to​produce
this​guidance;​the​scoring​model,​described​in​the
document​“Scoring​Methodology,”1 outlines​a​way​to
systematically​understand​the​security​profile​of​an​entity
1
in​the​supply​chain.​Modeling​threat​scenarios​as​they
apply​to​data​allows​analysis​of​that​type​to​have​more
value​and​more​contextual​relevance,​which,​in​turn,
enables​concrete​understanding​of​the​potential​threats​to
which​data​could​be​subject​when​in​another’s​custody​or
under​another’s​stewardship.
This​white​paper​discusses​how​to​adapt​threat​modeling
to​data​in​transit​and​data​at​rest​as​a​strategy​to​put​forth
a​more​holistic,​comprehensive​and​continuous​model​for
understanding​data​risk​and​for​analyzing​potential​risk​in
the​supply​chain.​It​is​not​exactly​a​one-to-one​mapping
between​the​process​for​creating​an​application​threat
model​and​performing​the​same​exercise​with​data,​but—
with​a​few​tweaks—it​is​achievable​and​useful.​After​the
model​is​in​place,​it​can​be​directly​incorporated​into​an
ongoing​continuous​assurance​program​that​ensures​that
data​are​optimally​protected​against​changing​threat
conditions,​changes​in​how​data​are​used,​changes​in
business​process​and​any​other​future​changes.
relates​to​legal,​regulatory​and​other​mandatory
requirements​that​govern​how​data​are​(or​can​be)​used.
Practical Challenges
From​a​practical​standpoint,​how​data​are​stored,
processed​and​transmitted​is​changing.​The​following
transformations​are​currently​underway:
• ​Data consolidation—Data​are​becoming​denser​in​some​places.​New
data​processing​methods​and​increased​analytics​capability​are
6 CONTINUOUS ASSURANCE USING DATA THREAT MODELING
causing​data​stores​to​consolidate​and​data​to​become​more
concentrated.​For​example,​data​lakes​and​other​large-scale​big​data
and​business​intelligence​techniques​are​increasing​the​amount​of​data
stored​in​certain​locations.
• ​Data ubiquity—Data​are​becoming​more​pervasive,​more​ubiquitous​in
their​spread​throughout​the​enterprise.​Data​may​be​present​(whether
transiently​or​otherwise)​throughout​the​entirety​of​the​on-premise
technology​substrate​and​increasingly​at​service​providers​and​business
partners.
• ​Data expansion—Data​are​becoming​more​plentiful.​Increasing
amounts​of​data​are​being​generated​from​an​increasingly​diverse​array
of​systems,​processes,​platforms​and​environments.
• ​Processing parallelization—Data​are​increasingly​being​processed​in
parallel​as​multiple​systems​subscribe​to​and​process​information​in​an
increasingly​complex​web​of​application,​system​and​process
interdependency.
Note​that​these​are​not​the​only​changes​occurring;
individual​enterprises​may​be​seeing​other,​related​or
unrelated,​transformations,​depending​on​business
activities,​industry,​regulatory​constraints​or​any​other
number​of​factors​unique​to​them.​The​listed​changes​are
highlighted​because​they​impact​the​complexity​of
ensuring​robust​data​protection​and​are​also​near-
universal​to​most​enterprises​in​their​applicability.
These​changes,​in​turn,​create​practical​challenges.
Fundamentally,​it​can​be​very​difficult,​as​a​practical
problem,​to​know​where​data​are​stored​and​the​pathways
they​take​throughout​the​environment.​Many​enterprises,
including​those​that​have​an​accurate,​current​and
detailed​asset​inventory​for​physical—or​even​virtual—
assets,​may​have​a​much​less​clear​idea​of​where​data
reside,​how​they​are​used​or​how​they​get​from​place​to
place.​As​anyone​who​has​ever​tried​to​do​it​can​attest,​it
is​particularly​challenging​to​create​a​map​or​inventory​of
data​that​is​as​reliable,​current​and​well​understood​as
physical​or​virtual​asset​inventories.​This​means​that,​for
many​enterprises,​it​is​very​challenging​due​to​time​and
resource​constraints.​A​best-case​scenario​is​just​being
able​to​classify​data;​many​enterprises​have​given​up​on
trying​to​catalog,​inventory​or​map​all​data​so​that​they
can​be​labeled​and​rules​can​be​applied.
© 2018 ISACA. All Rights Reserved.
Although​this​is​a​natural​consequence​of​the​fact​that
data​are​so​omnipresent,​this​problem​tends​to​compound
over​time​in​difficult-to-anticipate​ways.​For​example,​an
enterprise​invests​in​enhanced​analytics​capabilities​to
derive​more​and​better​insights​from​existing​data.​As​it
starts​to​realize​value​from​its​analytics​capability,​the
enterprise​might,​for​example,​investigate​data​lake
strategies​or​other​methods​of​consolidating​and
collecting​existing​data.​Although​these​methods​of
consolidating​and​collecting​existing​data​can,​in​theory,
offer​an​opportunity​to​better​manage​the​data,​as​a
practical​exercise,​they​are​often​compounding​factors​to
already​existing​challenges​in​managing​data.​Likewise,​as
enterprises​become​more​externalized,​that​is,​as​they
incorporate​external​services,​such​as​cloud​providers​and
other​participants​in​the​supply​chain,​the​management
challenges​also​compound​as​new​participants​(some​of
which​might​be​outside​the​enterprise)​are​now​included
in​the​mix​and​need​to​be​taken​into​account.​This​means
that​multiple,​potentially​overlapping​responsible​parties
each​play​a​role​in​the​overall​data​protection​picture,
which​serves​to​make​the​already-complicated​picture
more​complex.
Regulatory Requirements
In​addition​to​the​practical​challenges​that​enterprises
face​in​keeping​track​of​data​throughout​their​lifespan,
several​regulations​and​standards​impact​data​in​difficult
ways.
The​General​Data​Protection​Regulation​(GDPR)​pertains
to​data​that​intersect​with​operations​or​activities​that
enterprises​might​perform​in​the​European​Union​(EU)​or
that​impact​information​that​enterprises​might​hold​about
persons​in​the​EU.​Even​for​businesses​for​whom​GDPR​is
not​directly​applicable,​other​geographically​bounded
regulatory​considerations​are​useful​to​consider.​For
example,​breach​disclosure​requirements​in​specific
jurisdictions,​such​as​US​state​laws,​specify​requirements
for​notification​if​data​about​customers​are​breached.
In​addition​to​regulatory​constraints​that​are
7 CONTINUOUS ASSURANCE USING DATA THREAT MODELING
geographically​bounded,​such​as​the​GDPR,​enterprises
also​must​consider​regulations​based​on​the​industry​in
which​they​operate​or​the​type​of​activities​they​perform.
For​example,​the​Payment​Card​Industry​Data​Security
Standard​(PCI​DSS)​governs​cardholder​data​that
enterprises​have​or​retain​about​customers,​which​is​more
applicable​to​a​merchant​or​in​a​retail​context.​The​US
Health​Insurance​Portability​and​Accountability​Act
(HIPAA)​and​Health​Information​Technology​for​Economic
and​Clinical​Health​(HITECH)​Act​apply​to​health
Data Threat Modeling
This​can​be​a​difficult​landscape​to​navigate.​The
challenge​is​to​move​the​process​of​accounting​for​data​in
a​structured,​systematic​way​higher​on​the​list​of​an
enterprise’s​priorities.​One​option​to​accomplish​this
challenge​is​by​applying​security​threat​modeling
principles​to​data.​This​is​not​terribly​difficult​to​do​but​it
does​require​a​fairly​detailed​understanding​of​the​security
threat​modeling​process​(i.e.,​its​purpose,​goals​and
intended​outcomes),​planning​and​discipline.
Threat​modeling​is​a​systematic​process​to​decompose
an​application​into​its​various​parts​so​that​each​can​be
analyzed​from​an​attacker’s​point​of​view.​As​a​quick
summary,​this​is​accomplished​by​enumerating​the
various​supporting​elements​that​comprise​the
application,​systematically​mapping​the​exchange​of​data
between​those​elements​and​conducting​a​thorough
analysis​of​any​threats​that​they​can​encounter​at​each
interaction​point​between​those​elements​or​components.
In​brief,​the​threat​modeling​process​involves​the​following
high-level​steps:
1 Identify​subcomponents,​dependencies​and​interaction​points.
2 Discover,​inventory​and​evaluate​threats.
3 Mitigate​the​risk​brought​about​by​threats.
There​are​multiple​sources​of​information​about​the​threat
© 2018 ISACA. All Rights Reserved.
information,​and​govern​the​data​stored​by​a​health
insurance​or​healthcare​provider.
As​noted​with​the​practical​challenges​of​managing​data,
these​regulatory​requirements​combine​to​form​multiple,
potentially​overlapping​requirements​that​affect​specific
types​of​data​based​on​what​they​are,​how​they​are​used,
the​region​to​which​they​pertain,​etc.​Thus,​the​ability​to
understand​the​data​is​more​important—and​more
difficult—than​ever.
modeling​process;​each​uses​slightly​different​terminology
to​describe​these​tasks.​For​ease​of​understanding,​this
publication​provides​a​relatively​simplified​view​to​briefly
describe​the​process​and​keeps​the​steps​purposefully
generic.
Identify Subcomponents,
Dependencies and Interaction
Points
To​evaluate​the​threats​that​an​application​will​encounter
in​the​field,​one​first​needs​to​understand​how​the
application​operates.​Typically,​to​threat​model​an
application,​one​starts​by​decomposing​the​application
into​its​component​elements​and​mapping​out​how​those
components​interact​with​each​other.​During​this​process,
any​supporting​elements​are​included,​such​as​external
elements​(e.g.,​supporting​libraries),​entry​points,
interaction​points​that​might​be​accessible​to​an​attacker,
dependencies​or​any​other​element​of​the​application​to
be​modeled​in​further​detail.​During​this​process,​one
typically​creates​an​artifact,​such​as​a​data​flow​diagram,
that​illustrates​graphically​how​data​are​exchanged
between​elements.​Figure 1 shows​an​example​data​flow
diagram​for​a​small,​shopping-cart​style​application.
 8 CONTINUOUS ASSURANCE USING DATA THREAT MODELING

Payment
information PAY M E N T
PROCESSING

Order

CUSTOMER
WEB SHOP Order
details

FULFILLMENT

FIGURE 1: Data​Flow​Diagram​for​a​Small,​Shopping-Cart​Style​Application

The​data​flow​diagram​outlines​the​interaction​points STRIDE​is​an​acronym​that​stands​for:2
between​the​major​components,​including​how​and​where • ​Spoofing​identity
data​are​transmitted​between​those​entities.​Additional • T
​ ampering​with​data
2

information​can​be​added​to​the​data​flow​diagram, • ​Repudiation
including,​for​example,​supported​business​processes, • ​Information​disclosure
storage​of​information​at​rest​and​any​other​information • ​Denial​of​service
that​is​pertinent​to​analyze. • ​Elevation​of​privilege

Discover, Inventory and Evaluate

Each​item​in​the​STRIDE​acronym​represents​a​possible
area​of​exposure​for​the​application,​i.e.,​a​specific

Threats technique​that​an​attacker​might​employ​to​misuse​that
application.
After​the​flow​is​mapped,​the​next​step​is​to​systematically
analyze​the​map​from​an​attacker’s​point​of​view.​To​do DREAD​is​an​acronym​for:3
this,​each​of​the​interaction​points​identified​during​phase
3

• ​Damage
one​is​examined,​and​potential​avenues​of​attack​or • ​Reproducibility
exposure​are​evaluated​for​each.​Typically,​a​defined, • ​Exploitability
known​taxonomy​of​threats​is​used​to​ensure​that​the • ​Affected​users
complete​set​of​possible​threats​is​analyzed;​for​example, • ​Discoverability
the​STRIDE​or​DREAD​models​are​often​used​to
accomplish ​this.

2
Microsoft™,​“The​STRIDE​Threat​Model,”​12​November​2009,​https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee823878(v=cs.20)
Openstack,​“Security/OSSA-Metrics,”​https://wiki.openstack.org/wiki/Security/OSSA-Metrics#DREAD
2

3
3

© 2018 ISACA. All Rights Reserved.

9 CONTINUOUS ASSURANCE USING DATA THREAT MODELING

Similar​in​nature​to​STRIDE,​DREAD​categorizes​the
Mitigate the Risk Brought About
by Threats
vulnerability​according​to​its​characteristics​rather​than
specific​technique.
After​the​specific​threats​are​identified,​the​next​step​is​to
These​models​can​be​used​either​together​on​the​same
put​in​place​mechanisms​to​address​the​specific​areas
threat​model​or​in​parallel​(one​using​STRIDE​and​one
that​are​identified​during​the​modeling​process.​Specific
using​DREAD)​to​provide​a​set​of​possible​threat​types​or
measures​can​be​built​into​the​application​logic​itself,
characteristics​that​an​application​may​encounter.
mitigated​through​some​other​means​(e.g.,​an​operating
Typically,​during​an​application​threat​modeling​exercise,
system​or​network​control),​accepted,​or​addressed
each​item​in​the​taxonomy​is​evaluated​for​its​applicability,
through​normative​risk​management​activities.​The
impact,​feasibility,​etc.​STRIDE​and​DREAD​are​the​most
strategy​employed​for​the​application​threat​modeling
popular​approaches​used​in​systematic​application​threat
mitigation​or​resolution​activity​is​the​same​as​putting​in
modeling,​but​they​are​not​the​only​approaches.​Any
place​specific​mitigation​countermeasures​during​any
taxonomy​or​categorization​system​can​be​employed​as
other​risk​management​exercise.
long​as​it​is​comprehensive​and​can​be​applied​to​the
task.

Extending to Data Life Cycle

Management
This​model​can​be​productively​extended​to​data​and
applications,​with​a​few​minor​adjustments​to​allow​for
the​unique​threat​characteristics​of​data.​A​similar
process​is​followed,​but​instead​of​systematically
analyzing​and​addressing​the​interaction​points​for​a​given
application’s​components​or​supporting​functionality,​the
process​is​used​to​evaluate​the​data​that​might​be​stored
or​transmitted​by​the​enterprise.
Just​as​the​application​threat​modeling​process​allows​for
examination​of​an​application​from​an​attacker
perspective,​so​too​can​data​be​examined​(when​storage,
processing​and​transmission​mechanisms​are
enumerated​and​systematically​analyzed).​From​this
vantage​point,​data​elements​can​be​analyzed​as​an​end-
state​objective​of​an​attacker​campaign,​and,​by​so​doing,
individual​pathways​to​data,​including​potential​weak
points​and​threats,​can​be​identified,​risk​of​threat​can​be
mitigated​and​countermeasures​can​be​selected.​Doing
this​entails​a​few​key​changes​to​the​application​threat
modeling​process​described​previously:
1 Clear​definition​of​scope​of​analysis
2 Extension​of​mapping​technique​to​data
3 Extension​of​analysis​to​include​data​issues
Scope Definition
Extending​the​threat​modeling​concept​to​data​starts​with
a​clear​understanding​of​the​scope​of​what​will​be
assessed.​Applications,​by​their​nature,​have​a​defined​and
limited​scope;​although​some​may​be​larger​than​others,
the​scope​of​the​threat​modeling​for​an​application​is
constrained​by​the​components​within​the​universe​of​the
application.​Unlike​applications,​data​are​generally​wide-
ranging​and​ubiquitous.
Therefore,​it​is​important​to​narrow​the​subset​of​what​is
under​consideration​for​a​data​threat​model​to​something
that​is​manageable.​Trying​to​model​the​entirety​of​the

© 2018 ISACA. All Rights Reserved.

 10 CONTINUOUS ASSURANCE USING DATA THREAT MODELING

enterprise’s​data​at​once​is​seldom​practicable;​however,
by​restricting​the​scope​of​the​analysis​to​a​subset​of​the
environment,​the​feasibility​becomes​much​more​realistic.
This​can​be​done​in​a​several​ways,​but​the​goal​is​to
select​a​narrowly​defined,​bounded​and​manageable
subset​to​which​to​apply​this​exercise.​This​can​be​a
subset​based​on​a​geographic​or​logical​location​(for
example,​a​data​center​or​specific​physical​location);​it​can
be​a​specific​business​process​and​the​components​and
systems​that​support​it;​or​it​can​be​any​other​criteria​that
make​sense​for​the​enterprise​environment.
Adaptations​are​required​to​do​this.​Unlike​an​application
in​which​the​DFD​addresses​specific​components​within
the​application​scope,​the​focus​is,​instead,​on​anywhere
the​data​are​stored,​processed​or​transmitted.​Instead​of
looking​at​individual​objects​or​subcomponents​of​an
application,​another,​alternative​unit​is​selected​and​used
for​examination,​for​example,​physical​or​virtual​hosts.
Depending​on​the​specific​environment,​this​can​also​be
application​containers,​components,​processes,​etc.​It​is
important​to​select​the​most​granular​unit​for​systematic
examination​of​threats​and​ensure​that​it​is​granular
enough​to​allow​rigorous​and​thorough​examination,​but

Mapping not​so​granular​that​mapping​is​unmanageable.

After​a​subset​to​which​to​apply​the​process​is​selected,
the​next​step​is​to​adapt​the​modeling​process​to​allow
the​enterprise​to​discover​where​the​data​are​stored,
processed​or​transmitted​within​that​scope.​There​are
many​ways​to​accomplish​this,​but​a​straightforward​way
is​to​use​the​data​flow​diagram​(DFD)​as​per​the
application​threat​model.
Next,​the​mapping​process​is​adapted​to​include​other
data​beyond​just​those​that​are​exchanged​between​the
atomic​units​selected;​for​example,​data​that​are​stored
and​their​locations.​Where​and​how​data​are​exchanged
between​entities​are​mapped;​where​data​are​stored​is
included​in​the​mapping.​An​example​of​this​adaptation,
using​the​application​DFD​from​figure 1 as​an​example,​is
illustrated​in​figure 2.4 4

4
Note​that​this​example​is​a​simplified​version​for​illustration​purposes​only.​There​are​more​contextual​applications​on​the​market​to​show​data​flows;
see,​for​instance,​https://www.ibm.com/support/knowledgecenter/en/SS6RBX_11.4.2/com.ibm.sa.process.doc/topics/c_DFDYourdonDeMarco.htm.
4

© 2018 ISACA. All Rights Reserved.

11 CONTINUOUS ASSURANCE USING DATA THREAT MODELING

Stored:
• PAN
• Name
• Expiry
Order Payment
information PAY M E N T
SERVER/S

Order Stored:
WEB SERVER details • Name
CUSTOMER
• UID
Stored: • Shipping
• Cached session data addres s
• Order
manifest
FULFILLMENT • Shipping
(REST API) date/status

FIGURE 2: Adapted​Mapping

Figure 2 is​updated​to​reflect​a​change​from​application for​this​purpose,​an​enterprise​might​decide​to​adapt​them

components​to​(physical​or​virtual)​hosts​and​to somewhat​as​it​works​through​its​analysis.
accommodate​the​overlay​that​includes​the​information
The​salient​point​is​that​the​data​that​are​exchanged
about​the​stored​data​in​addition​to​data​that​are
between​entities,​the​entry​points​to​the​entities
transmitted​between​entities.​Obtaining​this​map​may
themselves​and​the​stored​data​are​being​looked​at.​The
take​some​time​and​investigation,​which​is​why​the
result​of​this​analysis​is,​from​a​risk​perspective,​a​list​of
reduction​of​the​scope​to​a​manageable​subset​in​the
potential​threats​to​assess,​treat​or​address​to​ensure​that
prior​step​is​so​important.
risk​goals​are​met.

Extension of Analysis Adaptation for the Supply Chain

After​the​map​is​created,​the​next​step​is​to​systematically
Extending​the​threat​model​in​this​way​allows​an
analyze​it​to​work​through​potential​threat​scenarios​the
enterprise​to​see​the​areas​where​data​may​be​subject​to
same​way​that​is​done​for​an​application​threat​model.
a​given​set​of​threats​not​only​when​they​are​stored​or
The​process​is​the​same​work-through​of​the​specific
processed​internally,​but​also​when​they​are​held​in​trust
entities​on​the​map,​evaluating​each​of​the​threats
by​a​service​provider​or​partner.​The​same​principle​of
systematically​and,​in​turn,​implementing
examination—iterating​through​the​various​places​where
countermeasures​as​appropriate.​However,​this​step​too
data​are​stored,​processed​or​transmitted,​and​analyzing
may​require​some​adaptation​or​customization​to​analyze
each,​in​turn,​from​an​attacker’s​point​of​view​against​a
specific​data​threats.​For​example,​although​STRIDE​and
defined​taxonomy—can​be​applied​to​third​parties​and​the
DREAD​are​useful​taxonomies​and​can​certainly​be​used
supply​chain.​Doing​this​can​add​value​when​combined

© 2018 ISACA. All Rights Reserved.

 12 CONTINUOUS ASSURANCE USING DATA THREAT MODELING

with​a​mechanism​to​assess​the​specific​controls,​posture
and​performance​(from​a​security​perspective)​of​the
partner​or​service​provider​in​question.
A​few​additional​pieces​of​information​are​required​to
support​this​for​analysis​of​the​supply​chain.​Specifically,
assessing​the​supply​chain​in​this​way​requires:
• ​A​working​understanding​of​the​suppliers,​service​providers,​vendors​or
other​third​parties​that​have​access​to​data
productively,​has​a​mechanism​in​place​to​maximize​the
efficiency​of​the​work​done​and​applies​rigor​to​areas​that
need​it​most.​These​items​are​best​addressed​from​a
process​standpoint:​​where​and​how​the​enterprise
integrates​the​technique​into​its​planning,​how​it
incorporates​the​results,​and​how​it​prioritizes​the​areas
on​which​it​focuses.​Higher-impact​or​higher-risk​areas
should​be​targeted​first.

• ​A​mechanism​to​identify,​document​and​ultimately​evaluate​the​security
Also,​the​specific​way​the​enterprise​adapts​the​technique

measures​and​controls​employed​by​the​vendors​as​they​apply​to​the
should​be​decided​ahead​of​time.​For​example,​if​an

enterprise​data
enterprise​decides​to​adapt​something​like​STRIDE​or

• ​If​the​enterprise​intends​to​monitor​the​risk​status​of​those​parties​over
DREAD,​it​should​formalize​the​adaptation​so​that​it​is

time,​a​mechanism​to​periodically​re-evaluate​and​monitor,​in​an
following​the​same​(or​a​similar)​process​across​areas.

ongoing​way,​the​items​noted​in​the​preceding​bullet
Given​the​time​investment​involved,​the​enterprise​will
likely​want​to​do​analysis​piecemeal​across​the
Each​of​these​items​should​be​evaluated​as​part​of​the
environment.​As​scope​is​selected​based​on​priority,
initial​round​of​threat​analysis.​This​evaluation​can​be
following​a​consistent​process​as​each​area​is​evaluated
combined​with​a​commercial​evaluation​of​supply​chain
means​that,​over​time,​a​complete​picture​will​develop.​If,
risk.​For​example,​SecurityScorecard,​ISACA’s​partner​in
however,​the​process​deviates​from​scope​to​scope,​the
this​white​paper,​outlines​an​objective​methodology5 for
resulting​picture​of​that​analysis​will​be​less​easily
evaluating​vendors​and/or​suppliers.​By​understanding
5

how​data​traverse​these​other​parties,​an​enterprise​can
build​a​much​more​complete​picture​and​supplement​the
value​derived​from​these​services.
integrated​into​a​single,​consistent​whole​that​can​be
easily​applied​and​utilized.
Last,​as​with​any​project,​an​enterprise​should​plan​out
optimal​use​of​resources​to​ensure​it​is​not​pulling​staff

Implementation Guidance away​from​more​critical​tasks.​Ideally,​the​information​an

To​put​this​approach​into​practice,​three​things​need​to​be
considered​thoroughly:
• ​Process—Procedures​and​processes​to​support​data​threat​modeling
• T
​ echniques—How​specific​techniques​will​be​adapted​to​support​the
enterprise
• ​Resources—Staffing​requirements​to​support​this​effort
From​a​process​standpoint,​the​enterprise​needs​to
ensure​that​it​is​able​to​use​the​results​of​the​analysis
enterprise​gets​from​this​exercise​ultimately​leads​to​more
efficient​use​of​resources,​but,​in​the​short​term,​to​avoid
weakening​its​overall​risk​profile,​an​enterprise​should​not
move​too​quickly​by​drawing​resources​away​from​critical
items.​If​an​enterprise​intends​to​extend​this​model​into
the​supply​chain,​additional​resources​may​be​impacted,
such​as​relationship​managers​and​procurement​or​other
areas​of​the​enterprise​that​may​monitor,​maintain​or
oversee​those​external​relationships.

5
5
Op cit SecurityScorecard

© 2018 ISACA. All Rights Reserved.

 13 CONTINUOUS ASSURANCE USING DATA THREAT MODELING

Continuous Assurance
As​can​be​seen​from​the​preceding​information,​a​threat
model​can​be​used​to​analyze​data,​but,​although​it​can
successfully​analyze​data​for​a​defined​subset​of​the
environment,​ideally,​the​goal​is​to​move​to​a​continuous
assurance​understanding​of​the​threats.​This​technique
can​be​a​vital​tool​in​helping​to​realize​that​goal,​but​it​does
not​automatically​happen​after​a​few​threat​models​are
completed​for​data​in​an​enterprise​environment.​Instead,
additional​planning​is​needed​to​make​continuous
assurance​understanding​of​the​threats​a​reality.
Continuous​auditing,​or​continuous​monitoring,​is​a​term
familiar​to​most​audit​and​security​practitioners.​In​this
context,​“continuous​assurance”​is​being​used​along
similar​lines,​but​it​is​important​to​differentiate​how​the
definition​of​the​term​“continuous​auditing”​differs​from
other​related​terms.
Perhaps​the​best​way​to​explain​is​to​start​by
differentiating​a​continuous​view​from​a​point-in-time
view.​​A​point-in-time​view​is​exactly​as​it​sounds:​​It​is
one-time​assessment​or​validation​that​gives​a​snapshot
of​what​is​being​evaluated​at​the​exact​moment​that​it​is
evaluated.​If​something​should​happen​subsequently,​the
conditions​will​have​changed​and​the​point-in-time
measurement​is​no​longer​valid.
In​a​continuous​view,​the​measurement​is​updated,​either
in​an​ongoing​way​or​at​an​interval​that​is​frequent​enough
to​have​negligible​impact.​It​is​a​continuous​evaluation​of
the​data,​rather​than​one​that​changes​(or​has​the
potential​to​change)​after​measuring​stops.
When​applied​to​an​audit​context,​continuous​audit​is​an
ongoing​verification​and​validation​of​something​as​it
occurs.​For​example,​if​an​enterprise​wants​to​extend
continuous​auditing​to​financial​reporting,​it​might​employ
a​method​to​check​and​validate​transactions​as​they
occur.​For​its​general​ledger,​billing​system​or​other
financial​reporting​system,​the​enterprise​has​integrity
checks​as​each​transaction​is​entered​that​validate​that
the​transactions​are​within​defined​policy​boundaries,​are
approved,​operate​within​business​rules,​etc.
The​same​is​true​of​continuous​monitoring​in​a​security
context.​Continuous​monitoring​refers​to​mechanisms
that​allow​the​enterprise​to​have​real-time​(or​nearly​so)
information​about​the​status​of​particular​security
controls​and​the​security​status​of​entities​in​its
environment.​Instead​of​evaluating​the​patch​status​of​a
host​at​a​given​point​in​time,​the​enterprise​monitors​the
patch​status​so​that,​if​that​host​drifts​out​of​compliance
with​expected​norms,​the​enterprise​is​alerted​and​can
take​(automated​or​manual)​action​to​address​the​drift.
With​continuous​assurance,​an​enterprise​can​be​notified
as​changes​happen​that​impact​its​understanding​of​the
threats​(and,​consequently,​risk)​to​which​its​data​are
subjected.

Specific Goals
Threat​modeling​data​can​support​an​enterprise’s​goal​of To​support​a​continuous​view​of​anything,​two​things​are
continuous​assurance​understanding​of​the​threats. needed:
Threat​modeling​can​also​help​an​enterprise​establish— • ​Something​to​measure
and​track—key​risk​indicators​(KRIs)6 related​to​its​data.
6

• ​A​way​to​perform​that​measurement​frequently​or​in​an​ongoing​way

6
6
Key​risk​indicators​(KRIs)​are​a​subset​of​risk​indicators​that​are​highly​relevant​and​possess​a​high​probability​of​predicting​or​indicating​important​risk.

© 2018 ISACA. All Rights Reserved.

14 CONTINUOUS ASSURANCE USING DATA THREAT MODELING

Modeling​the​threats​to​which​data​may​be​subject​helps employed​compared​to​how​that​same​data​may​be
to​establish​the​KRIs​that​are​important​to​the​enterprise. collected​internally.​For​example,​internally,​an​enterprise
may​use​a​data​loss​prevention​tool​to​mitigate​against
The​specifics​of​those​KRIs​vary​from​enterprise​to
exfiltration,​but​that​option​may​not​be​available​at​a
enterprise.​A​retailer​in​Europe,​for​example,​may​be
business​partner.​Instead,​the​enterprise​may​employ​a
interested​in​measuring​different​potential​risks​than​a
contractual​strategy​to​provide​analogous​information.
Japanese​bank;​however,​having​a​way​to​model​the
Likewise,​depending​on​the​operational​scope​of​the​KRIs
threats​is​the​first​step​to​determining​specifically​what​to
being​established,​an​enterprise​may​need​to​have
measure.​To​help​the​enterprise​establish​this​continuous
different​personnel​involved,​monitor​different​tools​or
view,​mapping​out​the​threats​can​identify​the​threats​that
adapt​the​method​by​which​it​is​gathering​data.
are​of​greatest​risk​impact​and​likelihood.​Then,​the

Putting Into Practice: Questions

controls​that​will​help​to​mitigate​or​offset​them​can​be
set​up​and​the​key​measurements​that​the​enterprise
wants​to​collect​(and​a​frequency​at​which​to​collect
to Evaluate
them)​can​be​determined.
An​enterprise​may​wish​to​consider​a​few​key​questions​to
Some​of​the​controls​and​measurements​can​be help​guide​its​implementation​of​continuous​assurance
automated.​For​example,​the​output​of​a​control​or​a​set understanding​of​the​threats:
of​inputs​from​threat​intelligence​sources​can​be​collected
• ​What​are​the​specific​risk​indicators​the​enterprise​will​use​to​measure
and​consolidated​into​a​measurable​metric​without​direct
how​individual​data​protection​controls​perform?
human​intervention.​Others​can​be​more​manual.​It​does
• ​What​are​the​specific​indicators​the​enterprise​will​use​to​measure
not​matter​how​they​are​collected,​as​long​as​the
changes​to​the​threat​environment?
measurements​that​are​most​valuable​to​the​enterprise
• ​How​will​the​enterprise​know​about​changes​to​business​processes​that
can​be​collected​and​done​in​a​way​that​does​not​require​a
might​occur​that​impact​data?
tremendous​amount​of​energy​or​staff​every​time​the
• ​How​will​the​enterprise​account​for​entities​in​the​supply​chain?
enterprise​wants​to​take​a​measurement.​The​frequency
• ​What​instruments​are​in​place​to​evaluate​control​performance​at​third
of​sampling​should​be​balanced​with​the​effort​required​to
parties?
collect​the​data​point​and​the​measurement​interval
• ​How​is​the​threat​environment​for​entities​in​the​supply​chain​being
required​to​provide​the​view​that​is​frequent​enough​to​be
measured?
continuous​and​actionable,​but​not​unmanageable​or​cost
• ​Who​will​be​informed​about​changes​to​a​third​party​that​might​impact
prohibitive.
the​enterprise?​How​will​those​individuals​communicate​that

The​specific​areas​to​include​in​the​measurements​also information​to​the​right​people​so​they​can​take​action?

need​to​be​determined.​Depending​on​the​measurements • ​What​valuable​information​can​be​repurposed​from​other​sources?

the​enterprise​wants​to​include​in​its​continuous What​is​being​collected​and​measured​now​that​could​contribute​to​a

assurance​view,​it​may​need​to​develop​specific more​continuous​view​of​the​threat​environment​or​risk​profile?

approaches​to​include​them.​For​example,​regarding • ​How​can​the​enterprise​future-proof​itself​to​ensure​that​it​is​building​on

entities​in​a​supply​chain,​an​enterprise​may​have​data past​efforts​in​the​measurements​collected​instead​of​re-creating​those

that​are​shared​with​business​partners,​suppliers​or​other efforts?

third​parties.​Depending​on​the​specific​context​and • ​Who​is​responsible​for​maintaining​and​monitoring​the​view​that​is​put

circumstances,​the​enterprise​may​want​to​ensure​that​it together?​Who​is​accountable​to​make​sure​it​gets​done​and​for​taking

is​obtaining​KRIs​or​other​information​about​the​data the​right​actions​as​needed​to​ensure​it​stays​relevant?

while​they​are​held​by​those​partners.​A​completely • ​What​is​the​amount​the​enterprise​is​prepared​to​invest​in​

different​set​of​tools​and​data​sources​may​need​to​be doing​this? Where​is​the​balance​between​actions​that​are​

helpful​and​valuable​vs. extra​ work ​th​e enterprise ​does ​not​

need​ and ​does ​not ​have ​time ​to make​ actionable?

© 2018 ISACA. All Rights Reserved.

15 CONTINUOUS ASSURANCE USING DATA THREAT MODELING
Conclusion
One​of​the​goals​of​continuous​assurance​of​data​threats
is​to​make​the​job​of​the​individuals​making​risk​decisions
for​the​enterprise​easier.​The​temptation​to​be​overly
aggressive​in​implementation​at​the​outset​can,​over​the
long​term,​undermine​efforts.​It​may​be​better​to​start
small​with​a​narrowly​defined​scope​and​build​from​there.
This​allows​practitioners​to​get​a​feel​for​the​approach​and
decide​if​it​is​right​for​them.​For​enterprises​that​struggle
with​data​protection​that​feels​out​of​control,​an​approach
like​this​one​can​help​bring​clarity​to​the​chaos:
• ​Because​it​is​systematic,​practitioners​can​know​that​there​are​no
hidden​problems​that​have​gone​unexamined.
© 2018 ISACA. All Rights Reserved.
• ​Because​this​model​allows​a​continuous​and​more​real-time​view,
practitioners​can​have​confidence​that​their​risk​profile​accounts​for
changing​conditions​and​evolutions​of​what​they​do—and​evolutions​in
what​attackers​do.
• ​Because​continuous​assurance​data​threat​modeling​is​customizable,​it
is​flexible​enough​to​work​in​almost​any​environment​that​stores,
processes​or​transmits​data.
Continuous​assurance​leverages​a​model​with​which
many​professionals​may​already​be​somewhat​familiar,
therefore,​the​skills​that​developed​while​putting​it​into
practice​are​directly​translatable​to​other​areas,
particularly​application​security.
16 CONTINUOUS ASSURANCE USING DATA THREAT MODELING

​Acknowledgments
ISACA​would​like​to​recognize:

Lead Developers ISACA Board of Directors

Fouad Khalil Robert Clyde, Chair Chris K. Dimitriadis, Ph.D.
CISA CISM ISACA​Board​Chair,​2015-2017
Head​of​Compliance,​ Clyde​Consulting​LLC,​USA CISA,​CRISC,​CISM
SecurityScorecard, Inc. INTRALOT,​Greece
Brennan Baybeck, Vice-Chair
CISA,​CRISC,​CISM,​CISSP Robert E Stroud
New York, NY, USA

Oracle​Corporation,​USA ISACA​Board​Chair,​2014-2015
Ed Moyle
CRISC,​CGEIT
Prelude​Institute Tracey Dedrick
XebiaLabs,​Inc.,​USA
Boston,​MA,​USA Former​Chief​Risk​Officer​with​Hudson
City​Bancorp,​USA Marios Damianides, Governance
Expert Reviewers Committee Chair
Leonard Ong
Ian Cooke CISA,​CISM
CISA,​CRISC,​CISM,​CGEIT,​COBIT​5
CISA,​CRISC,​CGEIT,​COBIT​Assessor​and Ernst​&​Young,​USA​
Implementer​and​Assessor,​CFE,​CIPM,
Implementer,​CFE,​CPTE,​DipFM,​ITIL CIPT,​CISSP,​CITBCM,​CPP,​CSSLP,​GCFA, Matt Loeb
Foundation,​Six​Sigma​Green​Belt GCIA,​GCIH,​GSNA,​ISSMP-ISSAP,​PMP CGEIT,​CAE,​FASAE
An​Post Merck​&​Co.,​Inc.,​Singapore Chief​Executive​Officer,​ISACA,​USA
Dublin,​Ireland
R.V. Raghu
Joshua McDermott CISA,​CRISC
CISA,​CEH,​CISSP,​PMP Versatilist​Consulting​India​Pvt.​Ltd.,​India
Jacksonville,​FL,​USA
Gabriela Reynaga
Jai Sisodia CISA,​CGEIT,​CRISC
CISA,​ITIL​V3 Holistics​GRC,​Mexico​
Sr.​IT​Consultant​-​Global
Baxter​International​Inc., India Gregory Touhill
CISM,​CISSP
Cyxtera​Federal​Group,​USA​

Ted Wolff
CISA
Vanguard,​Inc.,​USA

Tichaona Zororo
CISA,​CRISC,​CISM,​CGEIT,​COBIT​5
Certified​Assessor,​CIA,​CRMA
EGIT​|​Enterprise​Governance​of​IT​(Pty)
Ltd,​South​Africa

Theresa Grafenstine
ISACA​Board​Chair,​2017-2018
CISA,​CRISC,​CGEIT,​CGAP,​CGMA,​CIA,
CISSP,​CPA
Deloitte​&​Touche​LLP,​USA

© 2018 ISACA. All Rights Reserved.

17 CONTINUOUS ASSURANCE USING DATA THREAT MODELING

About​ISACA
1700​E.​Golf​Road,​Suite​400​
Nearing​its​50th​year,​ISACA® (isaca.org)​is​a​global​association​helping
Schaumburg,​IL​60173,​USA
individuals​and​enterprises​achieve​the​positive​potential​of​technology.
Technology​powers​today’s​world​and​ISACA​equips​professionals​with​the
Phone: +1.847.660.5505
knowledge,​credentials,​education​and​community​to​advance​their​careers
and​transform​their​organizations.​ISACA​leverages​the​expertise​of​its​half- Fax: +1.847.253.1755
million​engaged​professionals​in​information​and​cyber​security,​governance,
assurance,​risk​and​innovation,​as​well​as​its​enterprise​performance Support: support.isaca.org

subsidiary,​CMMI® Institute,​to​help​advance​innovation​through​technology.
Website: www.isaca.org
ISACA​has​a​presence​in​more​than​188​countries,​including​more​than​217
chapters​and​offices​in​both​the​United​States​and​China.

About​SecurityScorecard Provide Feedback:

SecurityScorecard​helps​enterprises​gain​operational​command​of​their www.isaca.org/Continuous-
security​posture​and​the​security​posture​of​their​third​parties​through Assurance-Using-Data-Threat-
continuous,​nonintrusive​monitoring.​The​company’s​approach​to​security Modeling
focuses​on​identifying​vulnerabilities​from​an​outside-in​perspective,​the​same
way​a​hacker​would.​For​more​information,​please​visit Participate in the ISACA
www.securityscorecard.com.​To​receive​an​email​with​your​company’s​current Knowledge Center:
score,​please​visit​instant.securityscorecard.com. www.isaca.org/knowledge-center

DISCLAIMER
Follow ISACA on Twitter:
ISACA​has​designed​and​created​Continuous Assurance Using Data Threat
www.twitter.com/ISACANews
Modeling (the​“Work”)​primarily​as​an​educational​resource​for​professionals.
ISACA​makes​no​claim​that​use​of​any​of​the​Work​will​assure​a​successful Join ISACA on LinkedIn:
outcome.​The​Work​should​not​be​considered​inclusive​of​all​proper
www.linkd.in/ISACAOfficial
information,​procedures​and​tests​or​exclusive​of​other​information,
procedures​and​tests​that​are​reasonably​directed​to​obtaining​the​same
Like ISACA on Facebook:
results.​In​determining​the​propriety​of​any​specific​information,​procedure​or
test,​professionals​should​apply​their​own​professional​judgment​to​the www.facebook.com/ISACAHQ
specific​circumstances​presented​by​the​particular​systems​or​information
technology​environment.

RESERVATION OF RIGHTS
© 2018 ISACA. All rights reserved.

Continuous Assurance Using Data Threat Modeling

© 2018 ISACA. All Rights Reserved.

Instantly Rate
& Understand the
Security Risk of
Any Company
Mitigate your third-party cyber risk with our
instant and continous monitoring platform.

Learn More & Get a Free Demo at: SecurityScorecard.com