Skip to content

Commit

Permalink
Merge pull request #8 from jsalowey/jsalowey-sec-cons
Browse files Browse the repository at this point in the history
Initial Security Considerations
  • Loading branch information
jsalowey authored Feb 26, 2024
2 parents aca2dac + 495ac3d commit 7db9a43
Showing 1 changed file with 17 additions and 2 deletions.
19 changes: 17 additions & 2 deletions draft-salowey-wimse-arch.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,8 +61,23 @@ TODO Introduction

# Security Considerations

# Threat Model
TODO Security
## Threat Model

### Traffic Interception

Workloads communicating within an an applications may face different threats to traffic interception in different deployments. In many deployments security controls are deployed for internal communications at lower layers to reduce the risk of traffic observation and modification for network communications. When a security layer such as TLS is deployed in these environments TLS may be termiated in various places including the workload itself and in various middleware devices such as load balancers, gateways, proxies, and firewalls. Therefore protection is provided only between each adjacent pair of TLS endpoints. There are no guarantees of confidentiality, integrity and correct identity passthrough in those middleware devices and services.

### Information Disclosure

Observation and interception of network traffic is not the only means of disclosure in these systems. Other vectors of information leakage is through disclosure in log files and other observability and troubleshooting mechanisms. For example, an application may log the contents of HTTP headers containing JWT bearer tokens. The information in this logs may be made available to other systems with less stringent access controls which may result in this token falling into an attackers hands who then uses it to compromise a system. This creates privacy risks and potential surface for reconnaissance attacks. If observed tokens can be reused, this also may allow attackers to impersonate workloads.

### Workload Compromise

Even the most well-designed and implemented workloads may contain security flaws that allow an attacker to gain limited or full compromise. For example, a server side request forgery may result in the ability for an attacker to force the workload to make requests of other parts of a system even though the rest of the workload functionality may be unaffected. An attacker with this advantage may be able to utilize privileges of the compromised workload to attack other parts of the system. Therefore it is important that communicating workloads apply the principle of least privilege through security controls such as authorization.

## Mitigating Token Theft




# IANA Considerations
Expand Down

0 comments on commit 7db9a43

Please sign in to comment.