I think we can sharpen the specs to better accommodate inbound signals from external providers. The current version focuses on the primary use case of signals being sent inside the same trust domain, but often in real life I suspect providers related to CNAPP, policy, posture, provenance, etc will often be external to the trust domain. Of course they have a trust relationship, but they might not be in the same trust domain practically speaking.
Use Cases:
- An external continuous monitoring platform or CNAPP (e.g., Wiz, Crowdstrike, or dedicated workload posture engines) detects anomalous behavior or a vulnerability status change and needs to alert the local credential service.
- A third-party threat intelligence feed asserts a posture failure that should trigger local policy enforcement, such as credential revocation or access degradation.
Proposed Areas for Modification:
To support this decoupled Transmitter/Receiver model, we should review and update the following sections:
- Section 1.1 (Scope): Add an explicit bullet point stating that WISE enables external security platforms to signal runtime posture and vulnerability changes inbound to a trust domain authority.
- Section 1.2 (Alignment with WIMSE Architecture): Perhaps we should add something here, to better facilitate external providers sending trusted, or indeed untrusted which has to be verified (?), signals into a trust domain.
- Section 4.3 (Authorization): I think here we should not make specific recommendations but rather state something to the effect that appropriate trust and authorization needs to be in place, but leave it to implementers to figure out exactly what this would mean for this. This is common practise for WIMSE.
Open Questions:
- Should we define specific subject identifiers for these external transmitters?
- Do the existing runtime/posture events fully cover the inbound scenario, or do we need additional attributes to specify the external origin of the signal?
I think we can sharpen the specs to better accommodate inbound signals from external providers. The current version focuses on the primary use case of signals being sent inside the same trust domain, but often in real life I suspect providers related to CNAPP, policy, posture, provenance, etc will often be external to the trust domain. Of course they have a trust relationship, but they might not be in the same trust domain practically speaking.
Use Cases:
Proposed Areas for Modification:
To support this decoupled Transmitter/Receiver model, we should review and update the following sections:
Open Questions: