-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
44 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
43 changes: 43 additions & 0 deletions
43
docs/events/wg_workshops/2024-03-14-march-meeting/workshop-satre.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,43 @@ | ||
# SATRE | ||
|
||
**Lead**: Simon Li | ||
|
||
## Notes | ||
|
||
- SATRE and AzureTRE | ||
- SHAIP (Safe Haven AI Platform, Canon R&D) SATRE assessment | ||
- TRE within Scotland safe haven network | ||
- Different scoring system to indicate whether SHAIP: | ||
- enables a requirement as a core part | ||
- supports a requirement as part of the overall TRE | ||
- requires a TRE to support for SHAIP | ||
- doesn't meet, possible gap | ||
- not required for SHAIP solution | ||
- Few missing requirements | ||
- Haven't found anything wrong in SATRE | ||
- Scottish DSH: found possible gaps on specialisms of capability | ||
- 33 N/A for SHAIP as a vendor inside a TRE | ||
- 21 Optional not relevant, 12 mandatories not relevant | ||
- 4 requirements as possible gaps in SHAIP. 3 optional one mandatory (on-prem encryption can be prohibitively expensive for very large datasets) | ||
- 32 requirements that SHAIP expects the TRE to provide (10 optional/recommended, 22 mandatory) | ||
- 12 requirements that SHAIP supports a TRE in implementing | ||
- Some capabilities can be summarised as "follow state of the art risk management", could be worth highlighting TRE specific capabilities? | ||
- Additional private score on how well something is implemented | ||
- Excel pivot table for different views, e.g. capabilities that must be implement, those where SHAIP must support TRE to implement, groups by pillar, etc | ||
- Can we change the SATRE scoring system to this? | ||
- Scoring is kind-of reverse of capability maturity model | ||
- CMRE role: role of someone in inplmenting | ||
- Can scoring system/roles be made public, for consideration as a replacement scoring system in SATRE | ||
- Some areas where it's impossible for a solution provider to implement on it's own | ||
- Can we split capabilities by domain e.g. technology provider, vs people, etc? Then different roles/providers can take care of evaluating different areas. | ||
- Would e.g. allow AzureTRE (product, not a deployment) to be evaluated against relevant part of SATRE. What's a feature, what's an SOP | ||
- ISO mapping, so ISO27001 accredited TREs _automatically_ tick relevant SATRE requirements | ||
|
||
- AzureTRE: initial evaluation | ||
|
||
- First impressions on using SATRE: | ||
- Getting started, 160 requirements, too many to evaluate before dinner | ||
- Smaller would be more accessible (e.g. best practice could be condensed into a single box) | ||
- SATRE very inclusive | ||
- Different mindsets, e.g. "data must not be shared between projects", but what about multiple related projects where data should be shared amongst limited projects? | ||
- But gap for federated |