> For the complete documentation index, see [llms.txt](https://itu.gitbook.io/dfs-security-assurance-framework/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://itu.gitbook.io/dfs-security-assurance-framework/dfs-security-vulnerabilities-threats-and-mitigation-measures-in-order-to-systematical/compromise-of-dfs-infrastructure.md).

# Compromise of DFS Infrastructure

Attacks as targeting the underlying infrastructure of the DFS ecosystem.

### Affected entity: MNO & DFS Provider

#### **Risk:** Infrastructure and data compromise

* **Vulnerability:** \_Insecure and inadequate access controls on user accounts (SD: access control)
  * [ ] **Control 9.1:** *Use multi-factor or multi-model authentication for access to DFS accounts.*

**Risk:** Service outage and inability to transact.

* **Vulnerability:** Untested Service restoration (SD: availability)
  * [ ] **Control 9.1:** *Deactivate and remove default accounts and credentials from databases, applications, operating systems, and other access interfaces that interact with the production DFS system.*
  * [ ] **Control 9.2:** *Review installation, vendor, support accounts, and access points to DFS systems and infrastructure. All of these accounts should be deactivated or allocated to appropriate user profiles*

#### **Risk:** Data exfiltration and modification, compromise of transaction integrity, and interruption of service

* **Vulnerability:** Inadequate data controls like inadequate implementation of ACID tests (Atomicity, Consistency, Isolation, Durability) on transactions, allowing them to exist in a partially completed state (SD: data integrity)
  * [ ] **Control 9.3:** *Perform end-to-end tests after any changes to the DFS, MNO, SP, and third party systems, include regression and capacity tests in the acceptance tests. Also, ensure there is a fall-back/blackout plan*
  * [ ] **Control 9.4:** *Schedule regular backups for DFS systems. Regularly test and securely store backups offline and offsite in an encrypted form*
  * [ ] **Control 9.5:** *Use standard ACID functionality of the databases to ensure transaction integrity. DFS operations should either succeed completely or fail completely.*

### Affected entity: Third-Party Provider

#### **Risk:** Inability for the user to transact.

* **Vulnerability:** Inadequate mechanisms to assure data integrity and over-reliance on external trust anchors (SD: non-repudiation)
  * [ ] **Control 9.6:** *DFS applications/3rd parties should support the use of digital signatures, a secure digital signature provides irrefutable evidence of the transaction's origin. Digital signatures are only valid as long as the PKI has not been compromised and must be tested with plans for assuring agility. By demonstrating that signing keys are adequately protected up to the root key, the DFS provider can withstand legal challenges about the authenticity of a specific user and desputed transactions.*