Token Trust & Traceability WG
Fortnightly for the risk assessment season.
https://codimd.web.cern.ch/D5V_dw5ZQFSidXrJKtvseA?view
# TTT Meeting 27/1/26
Attending: Matt, Luna, Maarten, Linda, Mischa, Donald
Apologies:
## Last Meeting
## Representing "Hacked" Users
ML Should we considers this in any particular class? It is relevant.
(Note on the to do list is the threat descriptions, but want a consensus for that)
MS - phishing is much more of an issue in the IAM age, which is a related problem.
Luna - same issue with office365 etc.
Luna - it's a stolen token? But also stolen identity if abuse is persistant.
Need to have definition if hacked.
DIfference between abusive user and a hacked user?
Difference between say, a hacked lxplus account and a hacked federated iam account.
ML previous incidents (cryptomining) were all user abuse.
ML - if a lot of security investigations need to be done
Luna - widening net too much, too many lines.
ML - we are going to look at this, particularly within the 4/5 split that we did.
4 is a one shot, so 5 is the best home
As Luna mentioned, to first order not much difference between a valid user abusing resources and a stolen account.
ML - for Threat-4 We have an example of tokens being leaked inadvertantly (FTS logs).
For threat 5 the abuse can be happen, but we should review category 5 with this respect/
Will need to update the Threat description for 5, to include this.
Tr-4 is not optimally named/have the right asset.
ML - maybe the asset should not be the primary key. 5 could now include digital identity.
Will need to rescore, but should try to merge first.
## Review of the Assessment
TR-1, Likelihood (2.5) too high, Impact might be too (3.5).
-moved to 3 and 2
Note improvements in IAM stability, and coming improvements.
ML - Worry should be from Ops perspective. not security perspective.
Luna - move Fractions to full numbers during this exercise.
MD - Should we have considered TR-2 when talking about hacked users?
Luna/ML - no, models things like minting your own tokens.
MD - notes that we have not many 1s for Likelhood, this is fair considering our "statistics."
TR -3 , both too high L(2.5), I(4).
Impact down to 2? Even less likely to happen now. Move to 2.
TR-6 round up Impact from 2.5 to 3. (at least)
TR-7 - keep as is (our current highest)
TR-4/TR-5
Discussing merging strategies, between workflows and the two threats.
Can't merge Power and Regular user rows.
TR-5 would be the "primary" if we merged with TR-4
Should also consider merging workflows.
Luna suggests:
Privilege user
Regular User
Privileged Workflow
And split Compute and Data if needed.
ML - Data and compute should be kept split.
Privileged workflow might not the right name. refers to FTS and pilot frameworks.
Two FTS cases, the "better" case could be described as a mitigation.
Might want to sperated other threats, like leaked in logs.
Discussed under TR-4. Should be included somewhere explcitly at the very least.
Luna - focus on mitigation and controls.
Some volunteers to go away and try to merge these as they best see fit, then compare this next time.
## AOB, Next Meeting
3pm CET Tuesday 10th as the next meeting? Clash with TIIME but okay.
Action on some of us to have a go at refactoring their own version of the spreadsheet.