7.     Identity Threats to the System
Adesso che il DFD è completato, bisogna stilare una lista con tutti gli elementi del DFD, perchè dovrai difendere questi elementi dagli attacchi.
Non verranno inclusi i processi complessi, invece sono inclusi i processi, i sistemi di salvataggio dati e i canali in cui i dati si muovono.
Faremo sempre riferimento al pet shop di un paio di post fà:
DFD Element Type
DFD Item Numbers
External Entities
Pet Shop customer (1.0)
 
Anonymous user (2.0)
 
Administrator (3.0)
 
 
Processes
Web Application (4.2)
 
User profile (4.5)
 
Membership (4.6)
 
Order processor (4.7.1)
 
Synchronous order processor (4.7.2)
 
Asynchronous order processor (4.7.3)
 
Sync/Async order processors (4.7.2 e 4.7.3)
 
Data access component (4.7.4)
 
Queuing component (4.7.5)
 
Data-access or queuing components (4.7.4 and 4.7.5)
 
Auditing engine (4.7.9)
 
 
Data stores
Web application configuration data (4.1)
 
Web pages (4.3)
 
User profile data (4.8)
 
Membership data (4.9)
 
Orders data (4.7.6)
 
Inventory data (4.7.7)
 
Asynch orders data (4.7.8)
 
Audit-log data (4.7.10)
 
Order and async orders data (4.7.6 and 4.7.8)
 
 
Data flows (partial list)
Anonymous user request (2.0->4.2)
 
Anonymous user response (4.2->2.0)
 
Anonymous user request/response (2.0->4.2->2.0)
 
Pet Shop customer request (1.0->4.2)
 
Pet Shop customer response (4.2->1.0)
 
Pet Shop customer request/response (1.0->4.2->1.0)
 
Web application reading configuration data (4.1->4.2)
 
Web pages read by Web application (4.3->4.2)
Una volta stilata la vostra lista, se vi accorgete d’avere due o più elementi dello stesso tipo (esempio, due o più processi) nella stessa trusted area, potete unire le entity. L’importante è analizzare le entità, che reputiamo uguali, con gli stessi threat.
Esempio, Anonymous user request (2.0->4.2) e Anonymous user response (4.2->2.0), sono elementi che possiamo semplificare perchè:
·         Il data flow usa la stessa tecnologia (HTTP over TCP)
·         Condividono lo stesso processo e le entità esterne (2.0 e 4.2)
·         Il contenuto dei dati in entrambe le direzioni è publico e anonimo.
Stessa cosa per i processi:
·         Synchronous order processor (4.7.2)
·         Asynchronous order processor (4.7.3)
possono essere accorpati perchè:
·         condividono gli stessi dati
·         sono nella stessa trusted area
·         sono scritti con lo stesso linguaggio
I campi depennati sono quelli che abbiamo potuto accorpare.
 
Adesso che la lista con gli elementi del DFD è completa, applicheremo lo STRIDE per tutti gli elementi nella lista, catalogandoli secondo STRIDE:
DFD Element type
S
T
R
I
D
E
External Entity
X
 
X
 
 
 
Data Flow
 
X
 
X
X
 
Data Store
 
X
*
X
X
 
Process
X
X
X
X
X
X
 
Notiamo * nella riga Data Store, alla colonna repudiation (R).
Se i dati contengono informazioni di login o di verifica, repudiation è un potenziale threat perchè se i dati vengono manipolati in qualsiasi maniera, chi lo fa riesce a nascondere le proprie tracce, o si può negare la propria transazione.
Tra tutti i data stores presenti nel DFD, solamente l’audit data store (4.7.10) deve preoccuparsi di un attacco di tipo repudiation.

Il perchè è semplice, è l’unico che si occupa di registrare i processi d’ordine:
·         Transaction date-time
·         Pet Shop customer ID
·         Pet Shop customer IP address
·         Order transaction ID
 
Una volta stilate entrambe le tabelle, inizieremo a determinare quali threat mappati nella tabella dello STRIDE possono colpire gli elementi catalogati nel DFD. E otterremo una tabella del tipo:
DFD Element type
Threat Types (STRIDE)
DFD Item Numbers
External entities
SR
1.0,2.0,3.0
Processes
STRIDE
4.2,4.5,4.6,4.7.1,4.7.2/3,4.7.4/5,4.7.9
Data store
T(R)ID
4.1,4.3,4.8,4.9,4.7.6/8,4.7.7,4.7.10*
Data flow
TID
4.1->4.2,4.3->4.2,2.0->4.2->2.0 etc
 
 
 
 
Come prima, notiamo le parentesi attorno la R e il simbolo *.
Il motivo è sempre per evidenziare un potenziale attacco di tipo repudiation in Audit-log data (4.7.10)
Tags: