Agile Application Security Framework: July 2015

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/308948578
Agile Application Security Framework
Technical Report · July 2015

DOI: 10.13140/RG.2.2.16171.03368
CITATIONS READS
0 1,514
1 author:
Graeme Burnett
Enhyper Ltd
19 PUBLICATIONS 1 CITATION
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Role Driven Recruitment using STEP profiles and position chaining View project
Cellular Automata Simulation on FPGA for Training Neural Networks with Virtual World Imagery View project
All content following this page was uploaded by Graeme Burnett on 08 October 2016.
The user has requested enhancement of the downloaded file.

Agile Application Secuirty Framework
Agile Applica*on Security Framework
Enhyper Ltd
Table of Contents
1
Introduc*on
The Agile Applica,on Security Framework is data lifecycle focussed and lightweight in that
there is considerable op,onality. It has a single interface: a checklist which serves as
documenta,on for the data flows of the applica,on or component that is mandated as part
of the sprint/epic. The checklist is documented using the principles of Usable Security¹⁰ i.e. it
is well annotated so the user can understand the concepts of data security and privacy, the
protec,on mechanisms provided by the infrastructure and those which must be created
during the development lifecycle. This offers security improvements at low cost, allows non-
experts to understand the applica,on and it's threat environment and is easy to iterate.
Threat modelling is presented in the context of the applica,on domain and details both
generic and specific threats.
Adherence to the above methodology does not remove the need to perform a
comprehensive penetra,on test prior to produc,on roll out but it raises the awareness of
security and privacy whilst capturing real-world threats which can guide the focus of the
penetra,on test. The target audience are assumed to be competent developers who are
fully conversant with the features and development piKalls of their chosen implementa,on
language therefore this document does not cover standard programming prac,ces and
language features.
Background
Informa,on Security is tradi,onally the domain of network engineering teams. With

internet connec,vity, there became a need for applica,ons to mi,gate vulnerabili,es such
as buffer overflows. This became a formal role of Security "Domain Experts" advising
developers and architects on how to design secure solu,ons using infrastructure and
middleware. Unfortunately, network engineers who became security experts lacked
applica,on development experience and had liPle influence with the developer community
leading to risk assessment becoming a post-implementa,on exercise that delivered liPle
value. It was also a costly and subjec,ve process (con,ngent on the exper,se of the domain
expert) so it was ra,onalised to a series of standards driven by internal/external audit which
led to a process which delivered liPle in the way of prac,cal security. In parallel with this,
penetra,on tes,ng was maturing and becoming a tool-driven process rather than a black
art. However, this too was highly specialised work, of subjec,ve quality and delivered a high
degree of "false posi,ves" which were difficult to diagnose. Remedia,ng the true posi,ves
was also post implementa,on and expensive in both resource and ,me to fix so business
owners were reluctant to test their applica,ons.
This situa,on has prevailed for several years and is now changing due to two factors: threat
actors and increasingly sophis,cated automated exploit tools. Security is one again on the
agenda. In the interim, some alterna,ve approaches were tried, such as threat modelling[⁷],
sta,c code analysis using standard security development paPerns. Two of the world's
largest organisa,ons in par,cular pioneered security threat modelling: Microso\ via the
work of Adam Shostack and the European Union with their Shields Project ⁸. Both
2
approaches were laudable in their intent but if their success is measured in the availability,
usage and developer exper,se of func,onal threat models, both can be considered failures.
The same can be said of Security Architecture PaPerns⁹ which took considerable effort but
suffered two problems: distance from the applica,on developers and mission creep - too
many irrelevant paPerns.
In order to succeed, Informa,on Security needs provide something of u,lity to the

applica,on development community, enhancing their delivery capability from project
ini,a,on to, in Agile terms, 'Done'.
3
Document Structure
There’s a quick start guide in the Appendix where you can find the Agile Security
Task
The document is organised thus:
1. Secure Software Development Lifecycle (SSDL): A quick overview of the

SCRUM/AGILE methodology, defining the roles and where the methodology
is augmented by the Agile Security Task.
2. Agile Application Security Methodology: This is a data centric capture,

analysis and threat model for the Agile sprint/epic deliverable. This
is added to the storyboard in the sprint or epic phase of the SCRUM
lifecycle which is signed off by the product owner.
3. Threat Modelling: A brief discussion on threat modelling from the attackers

perspective.
4. Mitigation Patterns: Mitigation provided by the infrastructure and software

techniques and design patterns that can be used.
5. Agile Application Security Task: The Agile task in detail. This is available as
a word document or a Confluence Template. I
4
The SCRUM Methodology
An Overview of the SCRUM Methodology
A history of Agile development methodologies can be found in¹. Applica,on developers

have adopted the Agile/SCRUM process as a way of coordina,ng the delivery of so\ware to
the end-user. It has gained wide acceptance due to the inclusion of Agile extensions in the
ubiquitous web-based toolset from Atlassian called JIRA Agile.
SCRUM Roles
The key benefits of SCRUM is that the developers get to chose what to deliver in the next
"sprint" and the user of the system gets what they ask for.
The three principal roles are:
Team Member:
• experts in the tools, architecture and techniques required to deliver the system.
Scrum Master:
• scrum process expert

• coach
• impediment bulldozer
• facilitator
Product Owner:
• Holds the product vision

• Represents the business
• Owns and priori,ses the product backlog
• Creates acceptance criteria for items
• Available to team members to answer ques,ons.
Applying SCRUM to Informa*on Security
Agile/Scrum is not about security per se but the delivery of systems which implicitly need to
be secure otherwise they put the business at risk. The product owner is responsible for the
informa,on security aspects of the system and it is the scrum master who is responsible for
ensuring that Informa,on Security task is on the task board at the appropriate stage.
5
This task comprises a checklist which details the data flows, their persistence,
transforma,ons and synthesis during the lifecycle of the process.
The security checklist integrated into the SCRUM framework means that the applica,on and
its data is understood at an early stage in development. As it is a mandatory task, it cannot
be put on the backlog.
6
Agile Application Security Methodology
Overview
The Agile Applica,on Security Methodology has the following steps:
• Architectural Model: pictorial representa,on of the architecture

together with a descrip,on of the high level components and how they
interact
• Data Analysis: list of data sources, sinks and synthesised data together
with applica,on configura,on files. Detailed full-lifecycle analysis of each
data feed covering physical, opera,on and security elements such as
access control, transport, persistence.
• Threat Modelling: Analysis of threats that apply to the components of

the system together with a STRIDE analysis
This exercise is completed for each sprint/epic and is updated as the whole
system progresses. An aggregate security analysis can be conducted for the
system as a whole from each component.
The end result is an accurate representa,on of the data artefacts and the
security aspects of the system which can be used to run automa,c and
directed penetra,on tests on the system with focussed coverage.
Architecture Modelling
Tools: Below is a list of tools which are useful for diagramming architectures:
YEd. hPp://www.yworks.com/en/products/yfiles/yed/
7
A simple tool wriPen in Java which is reliable, robust and scalable. It can
produce UML diagrams which is ideal for threat modelling.
Methodology: In addi,on to the diagram, the architecture should be described

in words, detailing each component and its func,on.
The detail will be captured as part of the checklist task.
8
Data Analysis
Overview
Data is the vector for many application threats. The majority of data is
transported via the network but there are other sources such as backup tapes,
keyboards, usb drives etc. Documenting these sources as used by an application
allows us to construct threat scenarios in the application context and where
appropriate, mitigate those threats. We use a simple quad chart approach with
axes of impact (low to high) and likelihood (again low to high) seeking to address
the high impact and likelihood threats as a priority.
Our approach to get use the SCRUM process to collect the data flows via the check
list which will allow security domain experts to analyse the elements of the data
flows which are necessary to provide a secure service with an acceptable service
level. Deviation from this SLA and issues with security are notified to the central
log analysis tool Splunk, an appropriate response initiated and remediation
managed.
Rather than looking from a pure threat point of view, we ask the developer
document the source IP, port number at the very least. This can, for example, be
used to drive firewall rules for that application.
Data Sources
The majority of application data will be from the network. There are subtle
threats which can compromise application availability (see CIA) and
Source Description Risk Mitigation

Network Data from network cards high Firewalls, application
firewalls, data input
libraries
Disk Disk space and resources, high Active space monitoring
memory, system processes and escalation
USB Malware high Data Loss Prevention
Data Input Threats
Threat Description Mitigation

Resource Disk space and resources, Active space monitoring and
Exhaustion memory, system processes escalation
Platform Hardware Errors, power Error detection and recovery
malfunction failures
9
Service Failure Facility dependency failure Retry and Escalation
Data Tampering Corruption of data hashing, cyclic
redundancy checks
Synthesised Data
Data that is created by the application from incoming data. For example a
transaction summary report on a per client basis.
Elevation of Security Level
One of the chief concerns is that the aggregation of data causes an increase in
information sensitivity. Appropriate measures must be taken to protect or prevent
this.
Data Synthesis Threats

Elevation in Disk space and resources, Active space monitoring and
secrecy memory, system processes escalation
Conflation/ Loss of information Retention of original copy,
Integrity metadata
Disclosure Reveal data to unauthorised Encryption
parties
Data Sinks
Data that is supplied to downstream systems.

Interception Disk space and resources, Active space monitoring and
memory, system processes escalation process
Consumption Failure for a downstream Escalation Process
Failure system to consume the data
resulting in retention and
downstream inaccuracies
Service Failure Failure of dependent service Escalation, notification
Data Tampering Data corruption Hashing, cyclic redundancy
checks, sequence checking
Application Configuration
10
Application configuration data is usually found in static files in a variety

of formats. It is a significant source of application errors and fraud.
Formats such as XML and comma separated values are complex
formats for humans to edit and maintain.
Some configuration can be refreshed during program operation, others
require a restart of the program. Adequate protection of the file needs to
be in place to ensure that the contents are not maliciously altered.
Best practice is to have Configuration as a Service (CaaS) in which valid

configuration is only supplied to an authenticated application on
demand. This ensures the correct configuration is delivered.
Local Disk and System Memory
This is the first persistence mechanism used by applications for a variety

of purposes. The analysis of security requirements needs to address the
level of protection required by this information in light of the value of the
information and consequences of a breach.
Network
This is the most common source and sink of data and can arrive over
multiple network connections.
11
Threat Modelling
An Overview of Threat Modelling

To identify the security requirements of software systems, many techniques have
been developed over the years, however, we are still in the situation where
security is an afterthought to the development process so it would appear that
many of these have been quietly dropped (e.g. DREAD which has been discontinued
by Microsoft.)
There are four main reasons for their failure:
• Additional Task: They don’t help the development process - they are seen
as an additional task
• Lack of Domain Knowledge: Focus on security terms and threats that are
usually alien to developers
• Subjective: Quality and coverage based on individual experience and time
allocated.
• Numerical: A numerical value does not measure security. A comprehensive
approach from design to penetration testing is more effective.
The security focussed check list answers these four points thus:
• Assists Development: Captures architecture, data flows and configuration

information to help document the product. Tasks that are expected of a
professional software engineer.
• LEAN: Minimalist approach, focusses on the discovery and documentation of
assets. Can be extended as required to be a comprehensive review. The
balance of these activities is between the software engineer and the
security domain expert.
• Delivery Focussed: Assists the developer by providing detailed
documentation of the system increasing knowledge and understanding.
• Secure Patterns: Familiarises and educates developers in secure application
development practises by highlighting coding techniques and infrastructure
facilities (such as F5 Networks) together with operational practises (logging
application transactions to determine SLA)
Threat Modelling and Enumeration

Definition: Threat modelling is the enumeration of threats which in simple terms
is creating a list of known and likely threats.
Deliverable: A list of threats in the operational context of the target to the

system, application or components together with their mitigation.
12
Caveats: By its nature it is a subjective process which is limited in coverage

therefore it must be backed by a penetration test which uses a variety of tools and
techniques to give greater coverage than any human driven approach.
In Practise: Threat modelling can be performed by security domain experts and

shared with software engineers, performed collaboratively with both engineers and
experts, or done by engineers without experts available. It is rare that the middle
case is performed due to the distributed nature of development so, in practise, the
first and last cases prevail.
Value: The value of creating a well annotated task adhering to the principles of
usable security, that involves building a threat model, gives the engineers a sense
of ownership and an understanding of the security model.
STRIDE
Categorisation schemes abound as discussed in the overview. STRIDE is useful in

the identification of threats by classifying attacker goals such as:
• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege
A threat list of generic threats organised in these categories with examples and
the affected security controls is provided in the following table:
STRIDE Threat List
Security
Type Examples
Control
Threat action aimed to illegally access and

Spoofi Authenticatio
use another user's credentials, such as
ng n
username and password.
13
Threat action aimed to maliciously

change/modify persistent data, such as
Tampe persistent data in a database, and the
Integrity
ring alteration of data in transit between two
computers over an open network, such as
the Internet.
Threat action aimed to perform illegal

Repud Non-
operations in a system that lacks the
iation Repudiation
ability to trace the prohibited operations.
Inform
Threat action to read a file that one was
ation Confidentialit
not granted access to, or to read data in
disclos y
transit.
ure
Denial
Threat aimed to deny access to valid
of
users, such as by making a web server Availability
servic
temporarily unavailable or unusable.
e
Elevat
Threat aimed to gain privileged access to resources for
ion of
gaining unauthorised access to information or to
privile
compromise a system.
ge
Conclusion
A task is added to the task board of a story/epic in order to capture
the data flows, events, processes and threats associated with an
application. The flows and their attributes are described in terms that
14
are easily understood by application developers. Info
When that task is added to the sprint/epic is decided by the SCRUM

master and the Product Owner. The latter takes the responsibility that
the application security task has been 'Done' before sign-off for
production use.
This task currently is a spreadsheet but will be integrated as a module

into the Atlassian JIRA Agile product. It serves two purposes: firstly,
helping application developers understand their data flows from an
information security perspective and secondly, making the risk
assessment process part of the design/development lifecycle.
The next step is to integrate security development patterns into the

process which will further enhance the security of developed systems.
15
References
# Description
1 Agile Software Development
http://en.wikipedia.org/wiki/Agile_software_development
A Precise and General Inter-component Data Flow Analysis
Framework for Security Vetting of Android Apps
2
http://www.ieee-security.org/TC/SP2014/posters/WEIFE.pdf
Informed Consent by Design

http://hornbeam.cs.ucl.ac.uk/hcs/teaching/GA10/lec9extra/
3
ch24friedman.pdf
A Brief Introduction to Usable Security

4 http://www.cc.gatech.edu/~keith/pubs/ieee-intro-usable-
security.pdf
OWASP Application Security Architecture Cheat Sheet
5 https://www.owasp.org/index.php/
Application_Security_Architecture_Cheat_Sheet
CaaS - Configuration as a Service
6 https://www.usenix.org/conference/ucms14/summit-program/
presentation/schottelius
Experiences Threat Modelling at Microsoft
7 http://www.homeport.org/~adam/modsec08/Shostack-
ModSec08-Experiences-Threat-Modeling-At-Microsoft.pdf
The EU Shields Project
8
http://cordis.europa.eu/project/rcn/85431_en.html
Security Architecture Patterns
9
http://enhyper.com/content/OOSecurityPolicy.ppt
Usable Security
10 http://www.cc.gatech.edu/~keith/pubs/ieee-intro-usable-
security.pdf
16
Definitions
Term Definition
Business data Sets of individual data elements grouped around a concept
entry meaningful to the business e.g. Traveler might be the Business
Entity and their name, address, telephone number etc. would
be the individual data elements.
CSRF Cross-Site Request Forgery
DAO Data Access Object. An interface that abstracts access to a
database or persistence mechanism.
HTTPS HTTP over TLS
Acronym for Spoofing, Tampering, Repudiation, Information
STRIDE Disclosure, Denial of Service, and Elevation of Privilege. Used
as part of the Microsoft approach to threat modelling.
Object/Relational Mapper. A library that maps an object-
ORM oriented definition of data to a relational database containing
that data.
XSS Cross-Site Scripting
Agile Applica*on Security Task
17
AHribute Detail
Sprint Name
JIRA Agile URI
Confluence URI
Descrip*on
Sign-Off
Role Names and Contact Details Date

Developers
SCRUM Master
Product Owner
Descrip*on
Agile Security Quick Start Guide
This process aims to capture the data flows of the current sprint in order to generate firewall
rules that permit these flows, document and improve the controls that are in place to
mi,gate aPacks them and ensure the system integrates into the opera,onal environment in
a way that can be measured and monitored.
For the components that are the focus of the current sprint/epic, here are the respec,ve
tasks:
Developers
• Architecture Diagram: graphically, textually, preferably both. This can be in the

source code or using one of the tools suggested below.
• Fill in the Agile Security Checklist: detail the data sources, sinks and any data
synthesised
⁃ At a minimum: list the host/port, file transfers, creden,al handling and
lifecycle. Without this, your component will not be able to communicate to
the rest of the infrastructure.
⁃ Data Valida*on: Detail how the applica,on deals with data valida,on as this
is a strong aPack vector. Consult the mi,ga,on sugges,ons below.
⁃ Op*onally: But very useful, document the data lifecycle, volumes, back
pressure, privileges, privacy etc. The more informa,on that is accurate, the
bePer we can ensure the applica,on is available and secure.
• Configura*on Files: List the configura,on files used by the applica,on and who
controls these.
18
• PlaRorm Integra*on: Ensure the target system deals with issues such as resource
exhaus,on, OS errors and logs an applica,on specific message
⁃ Authen,ca,on failures, input valida,on failures and resource usage are
security sensi,ve events and need to be logged
⁃ Log issues using a unique token adhering to the applica,on development
standard
⁃ For example, the standard applica,on specific message starts with a ~ (,lde)
e.g. “~E_AUTH_FAILURE: Repeated authen,ca,on failure (count=5)”
• Opera*onal Integrity: List threats to the opera,onal integrity of the system in terms
of availability if you know any (e.g. Data input dependencies, missed transac,ons
etc)
• STRIDE Analysis: Consider aPack vectors and decide whether they are applicable/
likely. If so suggest or seek mi,ga,on.
Scrum Masters
• Ensure that the Agile Applica,on Security Task reflects the applica,on accurately and
does not contain irrelevant informa,on before
Product Owners
Applica*on Details
Name
Descrip,on
Confluence
URL
Business
Area
Product
Owner
Host
Datacenter
Loca,on
PCI-DSS
Notes
19
Name The common name of the applica,on.
Descrip*on Give as much detail as you know of the applica,on
and its business context
Confluence URL A URL to the system documenta,on.
Business Area Which business area owns the system
Product Owner Name of the individual or role that is responsible for
the access control and privacy of the data
Host hostname(s) of the applica,on servers that make up
the system
Data Centre Loca*on Which data centre hosts the applica,on servers
PCI-DSS Is this applica,on affected by PCI-DSS requirements.
Special measures need to be taken to protect card
data if this applies.
Architecture Diagram
20
System Descrip*on
Describe each component of the system and how they interact.
Data Perimeter Analysis

List the sources and sinks of data. Detail data that is created via summarisa,on, aggrega,on
etc.
Sources
Name IP Address:Port Descrip*on

NNN.NNN.NNN.NNN:N
Data feed name Source system descrip,on
NNNN
21
Sinks
Synthesised
Notes
By default, all ports are closed, therefore you will, at a minimum, have to document
the ports that your application requires.
Data Feed Detail
For each data feed, complete the sec,ons that are relevant. See the sec,on below on Threat
Mi,ga,on/Controls for instruc,ons on how to apply this each data feed.
AHribute
Name
IP Address:Port Number
Transport (UDP, FTP etc)
Descrip,on
Access Control
Aggrega,on
Audit
Authen,ca,on
Configura,on Control
Confla,on
22
Encryp,on
En,tlements
Masking
On Demand Update/Replay
Persistence
Privacy
Resilience
SOC Integra,on
Tokenisa,on
Versioning
Whitelis,ng
Threat Mi*ga*on/Controls
For each data feed detailed in the previous sec,on, consider the list of controls
or threat mi,ga,ons for each. These are controls that are applicable to the
business model of Global Blue and are not intended to be architecturally
complete.
The list will be augmented as new security controls and paPerns relevant to
the opera,onal environment and business use cases are discovered.
Mi*ga*on Descrip*on
Access Control of file access using low level opera,ng

Control system mechanisms or higher level abstrac,ons such
as document sharing (e.g. Dropbox), en,tlements
etc.
Aggrega*o Data aggrega,on is a poten,al threat in that secrecy

n level can escalate significantly. For example, knowing
that a fault in one product is not important: knowing
that it exists across the product range is sensi,ve
informa,on.
Audit Data may have to be stored in a way which captures

the audit trail e.g. customer trading records.
Authen*ca Is the applica,on, user or service bona fide. Key in

*on avoiding man-in-the-middle aPacks.
23
Authorisat Does the applica,on, user or service have the

ion current privilege to perform the opera,on (aka
en,tlements). This may be revoked in real-,me e.g.
when a credit limit is breached.
Configurat Revision control of the configura,on files is part of

ion the change management process.
Control/
Versioning
Confla*on Data summarisa,on destroys informa,on and

therefore can reduce the data sensi,vity but also
provenance and accuracy making it difficult to
ascertain correctness of informa,on.
En*tlemen A token of en,tlement or bearer token can be used

ts as an asynchronous authorisa,on mechanism in low
grade systems. This is a par,cularly prevalent
technique in market data distribu,on e.g.
Masking Obfusca,on of data via subs,tu,on of informa,on

with asterisk as used in credit card receipts. The least
and most significant digits are s,ll visible.
On Request for the latest version of a resource such as a

Demand binary, configura,on or applica,on data. This can
Update/ occur when a quorum or services loses a member
Replay that has to enter a recovery stage in order to rejoin
services the quorum.
Persistenc Storage: where, for how long, what access profile is

e required? how long should it be retained? What are
the access requirements?
Privacy Does the data owner know what you intend to do

with their data and do you have the required
informed consent [³], authorisa,on and permission to
perform this ac,on.
24
Resilience Does this data require redundant delivery or

capture? There are many paPerns here - from
resilient disks to dual network cards and servers.
SOC Security events can be generated by the applica,on

Integ that are sent to the syslog(1) or windows event
ra*o mechanism. These events can be parsed by splunk
n and no,fied to a security opera,on center where a
predefined process can be invoked. These can be
login/logout, login failures, service level issues etc.
Tokenisa* Data that cannot be allowed out of a specific zone

on e.g. PCI data or that subject to geo-legisla,ve
constraint such as Swiss customer iden,fying data.
Versioning Is a version history required to be maintained. This is

different from configura,on control in that
maintaining versioned data can mean that different
version of a system can operate simultaneously but
consuming/producing the correctly versioned data
stream.
Whitelis*n By default, disallow access to all data sources.

g Whitelist data sources that the applica,on
consumes. Data sources that the applica,on emits
should be discoverable either by a web service, an
enterprise data directory or by sta,c documenta,on.
STRIDE Analysis
For each data feed in the data perimeter analysis, consider the aPack vector and decide if it
is applicable to this data feed. Choose an appropriate mi,ga,on technique or request
assistance from the SCRUM Master.
Applica*on Name
APack Applicable? Mi,ga,on

Spoofing
Tampering
25
Repudia,on
Informa,on
Disclosure
Denial of
Service
Eleva,on of
Privilege
26
View publication stats

Agile Application Security Framework: July 2015

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Agile Application Security Framework: July 2015

Transféré par

Droits d'auteur :

Formats disponibles

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Agile Application Security Framework

Technical Report · July 2015

The user has requested enhancement of the downloaded file.

Agile Applica*on Security Framework

Informa,on Security is tradi,onally the domain of network engineering teams. With

In order to succeed, Informa,on Security needs provide something of u,lity to the

The document is organised thus:

1. Secure Software Development Lifecycle (SSDL): A quick overview of the

2. Agile Application Security Methodology: This is a data centric capture,

3. Threat Modelling: A brief discussion on threat modelling from the attackers

4. Mitigation Patterns: Mitigation provided by the infrastructure and software

The SCRUM Methodology

An Overview of the SCRUM Methodology

A history of Agile development methodologies can be found in¹. Applica,on developers

The three principal roles are:

• scrum process expert

• Holds the product vision

Applying SCRUM to Informa*on Security

Agile Application Security Methodology

The Agile Applica,on Security Methodology has the following steps:

• Architectural Model: pictorial representa,on of the architecture

• Threat Modelling: Analysis of threats that apply to the components of

Methodology: In addi,on to the diagram, the architecture should be described

The detail will be captured as part of the checklist task.

Source Description Risk Mitigation

Data Input Threats

Threat Description Mitigation

Elevation of Security Level

Data Synthesis Threats

Threat Description Mitigation

Threat Description Mitigation

Application configuration data is usually found in static files in a variety

Best practice is to have Configuration as a Service (CaaS) in which valid

Local Disk and System Memory

This is the first persistence mechanism used by applications for a variety

An Overview of Threat Modelling

There are four main reasons for their failure:

• Assists Development: Captures architecture, data flows and configuration

Threat Modelling and Enumeration

Deliverable: A list of threats in the operational context of the target to the

Caveats: By its nature it is a subjective process which is limited in coverage

In Practise: Threat modelling can be performed by security domain experts and

Categorisation schemes abound as discussed in the overview. STRIDE is useful in

STRIDE Threat List

Threat action aimed to illegally access and

Threat action aimed to maliciously

Threat action aimed to perform illegal

When that task is added to the sprint/epic is decided by the SCRUM

This task currently is a spreadsheet but will be integrated as a module

The next step is to integrate security development patterns into the

Informed Consent by Design

A Brief Introduction to Usable Security

Agile Applica*on Security Task

Role Names and Contact Details Date

Agile Security Quick Start Guide

• Architecture Diagram: graphically, textually, preferably both. This can be in the

Data Perimeter Analysis

Name IP Address:Port Descrip*on

Name IP Address:Port Descrip*on

Name IP Address:Port Descrip*on

Data Feed Detail