Threatware Threat Model - Incomplete
For help populating see the help documentation.
Threat Model ID | SSC.TMD.1 |
Threat Model Document Name Name of this threat modelling document | Threatware Threat Model |
Current Version Author should increment when updating an Approved version | 1.0 |
Approved Version Only an Approver may change this value |
Version | Author Name | Author Role | Date | Change Log | Status | Approver Name | Approver Date |
1.0 | samadhicsec@gmail.com | Author | 2022-06-16 | Initial version | DRAFT |
Org | Samadhic Security |
Team | Threatware |
Repos The source code repositories of the Team systems in scope for this threat model | https://github.com/samadhicsec/threatware |
3rd Parties Org external systems (i.e. not managed by Org), relevant to this threat model, whether in-scope or not | Confluence, Google, GitHub |
Threatware is an AWS Lambda and CLI tool for verifying and managing threat models.
The following actions are possible:
This diagram is for Threatware deployed as an AWS Lambda function | This diagram is for Threatware deployed as a local python package, executable via the CLI |
For ALL components (those in the diagram above and those that should be in the diagram), capture basic information.
Name Short name of component | Hosting Stack e.g. Kubernetes, AWS (account) e.g. 3rd party | Purpose A brief description of the purpose the component serves IN THE CONTEXT OF THIS SYSTEM | In-Scope Yes/No | Tech Stack ONLY IF IN-SCOPE List of tech used for component e.g. Spring, Java |
User Agent | Client | Client for the API. Could be a browser. | No | |
API Gateway | AWS | For restricting access to Threatware lambda | Yes | AWS API Gateway |
Threatware Lambda | AWS | Retrieves threat models from a document storage location and performs specified actions. Management actions are written to a git repo. Configuration is downloaded from a git repo. Exactly the same code as Threatware CLI. | Yes | Python |
Threatware CLI | Client | Retrieves threat models from a document storage location and performs specified actions. Management actions are written to a git repo. Configuration comes from local files (although downloaded from a template git repo). Exactly the same code as Threatware Lambda. | Yes | Python |
Lambda Environment Variables | AWS Lambda | Store location and names of secrets required to download configuration. Sets log level. | Yes | AWS Lambda |
Lambda Storage | AWS | Store contents of cloned git repos. Stores git SSH keys. | Yes | AWS Lambda |
Secrets Manager | AWS | Store credentials for accessing document storage and git. | Yes | AWS Secrets Manager |
CloudTrail | AWS | Store Threatware lambda logs | Yes | AWS Cloudtrail |
ACS | AWS | Store container images used by AWS Lambda to invoke Threatware lambda | Yes | AWS ACS |
AWS IAM | AWS | Access management to AWS services | No | |
Confluence | 3rd Party | Document storage location for threat models | No | |
Google Docs | 3rd Party | Document storage location for threat models | No | |
Git Management Repo | GitHub | Storage location for threat model management data | Yes | GitHub |
Git Configuration Repo | GitHub | Storage location for Threatware configuration data | Yes | GitHub |
CLI Configuration | Client Filesystem | Local storage location for Threatware CLI configuration. Default is ~/.threatware/ | Yes | Filesystem |
Client Temp Storage | Client Filesystem | Temporary local storage for cloned git management repo (/tmp/tm_mgmt) | Yes | Filesystem |
Shell Environment Variables | Client Shell | Store configuration required to find local configuration. Sets log level. | Yes | Shell |
User’s Home Directory | Client | Usual location of user’s SSH keys (~/.ssh) | No | |
Template Git Configuration Repo | GitHub | If Threatware CLI can’t find local configuration it downloads configuration files from this git repo. Usually only happens the first time Threatware CLI is run. | No | |
Python Package Repo | Client Filesystem | The local python file system location where packages are stored. Threatware packages are installed here. Threatware config is also stored in the package (and in some scenarios might be the config used). | No |
For every in-scope component, list all; identities, authn and authz, that the component performs for incoming requests (do not list the identities the component uses to identify itself when communicating to other components). If a component does not perform authn/authz then answer ‘None’ in the relevant column. If a component receives no requests, then answer ‘n/a’ in the identity, authn and authz columns.
Component (In-Scope) Name from Details table (above) | Identity User/Group/Role or other identifier of an identity that makes requests to this component | Authentication How this component authenticates the identity | Authorization How this component authorizes the identity |
API Gateway | Anonymous Threatware lambda users | None | IP range validation |
Threatware Lambda | Anonymous Threatware lambda users | None | None |
Threatware CLI | Local OS user | Delegated to to Client OS | Delegated to Client OS File System |
Lambda Environment Variables | Threatware Lambda process | Delegated to AWS Lambda execution environment | Delegated to AWS Lambda execution environment |
Lambda Storage | Threatware Lambda process | Delegated to AWS Lambda execution environment | Delegated to AWS Lambda execution environment |
Secrets Manager | Threatware Lambda AWS IAM Role | AWS IAM | AWS IAM Policy |
CloudTrail | Threatware Lambda AWS IAM Role | AWS IAM | AWS IAM Policy |
ACS | Threatware Lambda AWS IAM Role | AWS IAM | AWS IAM Policy |
Git Management Repo | Threatware Lambda git user | SSH | Repository roles/permissions |
Threat Model Authors - (invoke manage.create /indexdata /submit) | SSH | Repository roles/permissions | |
Threat Models Approvers - (invoke manage.submit) | Delegated to the Git Server e.g. username/password | Repository roles/permissions | |
Git Configuration Repo | Threatware Lambda git user | SSH | Repository roles/permissions |
Threatware operations user (to make changes to config) | SSH, Delegated to the Git Server e.g. username/password | Repository roles/permissions | |
CLI Configuration | Local OS user | Delegated to to Client OS | Delegated to Client OS File System |
Client Temp Storage | Local OS user | Delegated to to Client OS | Delegated to Client OS File System |
Shell Environment Variables | Local OS user | Delegated to to Client OS | Delegated to Client Shell |
Functional Assets relate to the functionality implemented by the system being threat modelled, and are called out separately because they should capture the “end-goal” assets that an attacker is trying to compromise the security properties of.
Category Short category name to group related assets by | Name Short name of asset | Description Description of asset as it relates to this system being threat modelled | Confidentiality, Integrity Concerns Description of the impact if an attacker was able to perform an unauthorised read (i.e.confidentiality) or write (i.e.integrity) of this asset. Ignore any existing controls. Must be formatted as: C: An attacker that is able to read this asset could … I: An attacker that is able to change this asset could .. | Location The location(s) the asset is stored in. Can be a component, or pre-approved (by adding it to the template) location. |
Functional Data | Threat model document | The document that contains the threat model | C: An attacker that could read a threat model may learn about security weaknesses in a system I: An attacker that could change a threat model may be able to hide security weaknesses of a system | Confluence, Google Docs, Threatware lambda (in-memory) |
Threat model YAML | The YAML representation of the threat model in the threat model document | C: An attacker that could read a threat model may learn about security weaknesses in a system I: An attacker that could change a threat model may be able to hide security weaknesses of a system | Threatware lambda (in-memory), Lambda Storage, Client Temp Storage, Git Management Repo | |
Threat model index data | The approval current status of a threat model and various metadata | I: An attacker that could change this data could change which threat models were approved which may impact processes depending on the accuracy of this data | Threatware lambda (in-memory), Lambda Storage, Client Temp Storage, Git Management Repo | |
Threat Model version history data | The history of the different versions of a threat model | I: An attacker that could change this data could change which threat models were approved which may impact processes depending on the accuracy of this data | Threatware lambda (in-memory), Lambda Storage, Client Temp Storage, Git Management Repo | |
Audit Events | Lambda logs | Event data that relates to auditable actions performed by the system | C: An attacker that could read this data, if the log level was debug, could include data from the document I: An attacker that could change this data would affect the ability to debug the system or could hide calls to the lambda | Cloudtrail |
Technical Assets relate to all the assets that have security properties you want to ensure, but aren’t the “end-goal” for an attacker, and compromising one of these would then be used by the attacker to compromise a Functional Asset.
Category Short category name to group related assets by | Name Short name of asset | Description Description of asset as it relates to this system being threat modelled | Confidentiality, Integrity Concerns Description of the impact if an attacker was able to perform an unauthorised read (i.e. confidentiality) or write (i.e. integrity). Ignore any existing controls. Must be formatted as: C: An attacker that is able to read this asset could … I: An attacker that is able to change this asset could .. | Location The location(s) the asset is stored in. Can be a component, or pre-approved (by adding it to the template) location. | Function Asset(s) Affected Must match a Category or Name from the Functional Assets table. |
Configuration | threatware config files | Configuration files for the convert, verify, manage.* and measure actions. | Integrity: An attacker able to change these files could reconfigure how threat models are verified or managed | Lambda Storage, CLI Configuration, ACS, Python Package Repo | Functional Data |
| repo branch names | Repo branch names that control where updates get written to | I: An attacker that could change this could try to get updates made directly to the default branch | Lambda Storage, CLI Configuration, ACS, Python Package Repo | Threat model YAML, Threat model index data, Threat Model version history data |
Authentication Credentials | Git Server SSH key | Credential for accessing Git Server repo | C: An attacker able to read this value could modify the contents of the repo | Secrets Manager, Lambda Storage, User’s Home Directory | Threat model YAML, Threat model index data, Threat Model version history data |
| Confluence API key | Credential for accessing threat model documents on Confluence | C: An attacker able to read this value could read the contents of the threat model | Secrets Manager, CLI Configuration | Threat model document |
| Google Docs API key | Credential for accessing threat model documents on Google Docs | C: An attacker able to read this value could read the contents of the threat model | Secrets Manager, CLI Configuration | Threat model document |
Authorisation configuration | IP allowlist | The list of IPs that allow API Gateway allows to requests to come from | I: An attacker able to change this data could add their own IP allowing them to make requests | API Gateway | Threat model YAML, Threat model index data, Threat Model version history data |
Management repo default branch | By default it is called ‘approved’. This is the branch that Threatware is not allowed to commit directly to. It is defined in the configuration files. | I: An attacker able to change the configuration that specifies this branch could trick Threatware into committing directly onto the default branch | Lambda Storage, CLI Configuration, ACS, Python Package Repo | Functional Data | |
Git Management Repo permissions | The permissions that define who can merge pull requests to the default branch | I: An attacker than can change the permissions could grant themselves privileged access to change management data | Git Management Repo | Threat model index data, Threat Model version history data | |
Git Configuration Repo permissions | The permissions that define who can update the configuration repo contents | I: An attacker than can change the permissions could grant themselves privileged access to change configuration data | Git Configuration Repo | Functional Data | |
Locations | All URLs of components stored in config files | URL location of a component | I: An attacker able to change this data could receive or direct requests to an attacker controlled location | Lambda Storage, CLI Configuration, Python Package Repo | Functional Data |
Git Configuration Repo Location | Location of Git Configuration Repo | I: An attacker able to change this could control the Threatware configuration used | Lambda Environment Variables | Functional Data | |
CLI Configuration Location | Location of local configuration | I: An attacker able to change this could control the Threatware configuration used | Shell Environment Variables | Functional Data | |
Audit Data | Log Data | System log data used for performance, monitoring and debugging | C: An attacker able to read this data might see sensitive data that was unintentionally logged I: An attacker able to change this data might affect the operational ability to measure performance, monitor or debug. | Cloudtrail | Audit Events |
Provide sequence/data flow diagrams only to capture the complex flow of assets around the system.
Threat Model approval sequence diagram
n/a
Operational Security is only relevant if the team (who owns this threat model) operates the access control for one or many parts of this system e.g. approves requests for access to a system. If the team has no operational security responsibilities then answer ‘n/a’ to all questions.
Question | Answer Provide 1 column of answers per system that the team operates access control for. For additional systems, add extra columns | Answer |
What access control is operated by the team? | Access to Git management repo Read for everyone in the organisation. Write for Threatware (not on default branch). Write for TM approvers | Access to Git configuration repo Read for everyone in the organisation, Write on branches for team operations (so different teams can have their own config). |
How is access to the system requested? | Owner of repo | Owner of repo |
Who approves requests for access to the system? | Owner of repo | Owner of repo |
What access logs are generated for the system? | Delegated to Git Server operations | Delegated to Git Server operations |
How long are access logs kept? | Delegated to Git Server operations | Delegated to Git Server operations |
When is existing access to the system reviewed to remove those users no longer requiring access? | Delegated to Git Server operations to send out periodic reminders, which will be actioned when received | Delegated to Git Server operations to send out periodic reminders, which will be actioned when received |
The Threats and Controls table serves to:
THERE MUST BE ONLY 1 THREAT PER ROW (if multiple threats affect the same component/asset combination, use a new row)
Component(s) Name of asset from Details table that the threat applies to | Asset(s) Name of asset (or category of asset) from Functional/Technical Asset tables that the threat applies to | Threat Description of the threat that applies to the named asset(s) when present in the named component(s) | Control (Existing) Description of existing controls (newline separated) that help to mitigate the threat | Tickets Link to tickets to explore additional controls to further reduce risk |
Threatware lambda | Threat model YAML, Threat model index data, Threat Model version history data | As requests to lambda are only IP allowlisted it is possible to DoS the lambda (to either deny service or rack up large bills) | It is assumed operator of lambda has controls in place to prevent over-spending and to detect excessive usage |
|
Threatware lambda | Threat model YAML | Any user coming from an allowed IP address, but without access to a TM doc, can request the difference between two threat models, and so could infer the contents of either threat model | It is assumed that everyone able to originate requests from an allowed IP address already has access to the original TM document the version history data is based on. |
|
Lambda Storage | All assets stored in Lambda Storage | Sensitive data is persisted to disk and may be accessible to other lambdas or confuse another execution of the same lambda | According to https://aws.amazon.com/lambda/faqs/ “Each Lambda function receives 512 MB of non-persistent disk space in its own /tmp directory.“ The management data written to disk are deleted after every push to the origin Threatware removes any existing directory before cloning configuration files Threatware Lambda overwrites any existing SSH keys in the SSH config location. SSH keys are not deleted though. |
|
Git Management Repo | Threat Model version history data | The branch used for submitting a TM uses the TM doc ID, but if this was the default branch name then push would update the default branch without requiring approval | The default branch is a configuration parameter and the code checks that the branch being created has a different name |
|
Git Management Repo | Threat Model version history data | Previous pushes might interfere with future pushes | Existing remote branches for TM submissions are deleted, and new branches created each time submit is executed on the same TM |
|
Git Management Repo | All assets stored in Git Management Repo | Unauthorised access to the repo containing threat model metadata | Operational controls on who can read/write to the repo ensure no unauthorised access |
|
Secrets Manager | All assets stored in Secrets Manager | Unauthorised access to secrets | Specific IAM Roles are required to access the secrets in Secrets Manager |
|
API Gateway | IP allowlist | Unauthorised changes to IP allowlist | Specific IAM Roles are required to access the configuration API Gateway |
|
Cloudtrail | Audit Events | Unauthorised access to data in Cloudtrail | Specific IAM Roles are required to access the data in Cloudtrail |
|