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)