docs: update security assessment (#139)

* docs: update security assessment for 1.0.0 (DRAFT) * docs: rephrasing/update of threats Rephrased threat 1, removed (former) threat 2 as it is not applicable to this application. * chore: change small findings --------- Co-authored-by: Evelyn Gurschler <[email protected]>
eclipse-tractusx · May 22, 2024 · 6b61de5 · 6b61de5
1 parent f801982
commit 6b61de5
Showing 1 changed file with 36 additions and 10 deletions.
diff --git a/docs/architecture/Security_Assessment.md b/docs/architecture/Security_Assessment.md
@@ -1,16 +1,16 @@
 # Security Assessment SSI Credential Issuer
 
-|                           |                                                                                                |
-| ------------------------- | ---------------------------------------------------------------------------------------------- |
-| Contact for product       | [@evegufy](https://github.com/evegufy) <br> [@jjeroch](https://github.com/jjeroch)             |
-| Security responsible      | tbd |
-| Version number of product | 1.0.0                                                                                          |
-| Dates of assessment       | tbd: Assessment                                                                      |
-| Status of assessment      | Assessment Report                                                                            |
+|                           |                                                                                                          |
+| :------------------------ | :------------------------------------------------------------------------------------------------------- |
+| Contact for product       | [@evegufy](https://github.com/evegufy) <br> [@jjeroch](https://github.com/jjeroch)                       |
+| Security responsible      | [@szymonkowalczykzf](https://github.com/szymonkowalczykzf) <br> [@pablosec](https://github.com/pablosec) |
+| Version number of product | 1.0.0                                                                                                    |
+| Dates of assessment       | 2024-05-15: Initial Assessment                                                                           |
+| Status of assessment      | Done & Approved                                                                                          |
 
 ## Product Description
 
-The SSI Credential Issuer product is an REST API project with two Process Worker processes, so a pure backend component (without implementation of an user interface).
+The SSI Credential Issuer product is a REST API project with two Process Worker processes, so a pure backend component (without implementation of an user interface).
 
 The main purpose of the product is to provide authenticated CX Users the possibility to create credentials inside the issuer and holder wallet. Furthermore, it handles the revocation and expiry handling for credentials.
 
@@ -22,7 +22,8 @@ The SSI Credential Issuer is using following key frameworks:
 
 - .Net
 - Entity Framework
-[Development Concept](/Development%20Concept.md)
+
+[Development Concept](./Development%20Concept.md)
 
 ## Data Flow Diagram
 
@@ -80,6 +81,16 @@ flowchart LR
     CU-->|"IAM with OIDC \n [HTTPS]"|K
 ```
 
+### Additional information
+
+* The issuer stores the signed credentials in the database for holders to download their own credentials at any time.
+  * Unsigned credentials are stored to be compared with signed credentials before providing them to holders.
+* The signing of credentials is done externally, in the "Issuer Wallet". This application does not hold its own private signing key.
+* The issuer’s DID document is created by Issuer Wallet and published by the Portal itself, not the SSI Credential Issuer application.
+* The "Credential Service" can be used by a 3rd party (e.g., certificate holder) to retrieve the status of credential issuance. The "Issuer Service" is used as a starting point for requesting the issuance of a credential.
+* Credentials of technical users are stored in an encrypted manner.
+* All actions are logged within the Issuer DB.
+
 ### Changes compared to last Security Assessment
 
 N/A
@@ -90,7 +101,22 @@ N/A
 
 ## Threats & Risks
 
-TBD
+Only low–medium risks were identified during the security assessment:
+
+| 1       | Storage of credentials |
+| :------ | :------ |
+| Element | Issuer DB |
+| Threat  | (Privacy) Storing credentials of multiple parties violates best practices described by the W3C or recommended by *privacy by design* principles.<br>Consider only storing credentials as long as necessary (usually, until they are submitted to the holder).<br>See also [W3C: Verifiable Credentials Data Model v2.0, 8.12 Storage Providers and Data Mining](https://www.w3.org/TR/vc-data-model-2.0/#storage-providers-and-data-mining) and [8.16 Data Theft](https://www.w3.org/TR/vc-data-model-2.0/#data-theft) as well as *data minimization* in general. |
+
+| 2       | No technical limitation for batch-revocation of credentials |
+| :------ | :------ |
+| Element | Revocation Service |
+| Threat  | A single person with the appropriate permissions is able to revoke all credentials. Consider the implementation of a two-person rule for critical actions. |
+
+| 3       | Revocation of mismatched credentials |
+| :------ | :------ |
+| Element | Issuer Service/Revocation Service |
+| Threat  | If a difference between the unsigned and signed credential is identified, the credential should be revoked even if it was never provided to the holder. |
 
 ### Mitigated Threats