[Discussion]: DESIGN PRINCIPLE Observability

[jemrobinson]

Summary

Propose a principle that SATRE supports monitoring of how a TRE is used

Source

Discussion with @machintim

Detail

Logging high-level information about actions taken inside a TRE (eg. deployment or change of infrastructure, movement of data, access granted or revoked to users) is important for supporting a TRE, especially if there are data incidents.

Intended Output

No response

Who can help

@machintim @JimMadge @manics

[manics]

Active implies more than just logging- have you already discussed the scope of what else is included?

[jemrobinson]

I think "Active" was my term - I'll change it to something more neutral.

[machintim]

Logging may be a bit specific. Something more akin to traceability or actions being attributable. As this is a principle it should also include non-computing systems. So quality data related to processes. Who did, what when and by what authority for a process and what changed, when and why within a technical environment.

That wording is a mess but you get the idea.

[manics]

How about "Audit logs of user actions"?

[machintim]

@manics , goes beyond human actions, right? Maybe observability? First stab below @harisood

Human initiated and automated processes resulting in change within the TRE should be observable. Rationale In order to understand what is happening within the TRE both automated and human initiated processes should generate sufficient data. These data allow operators to measure the effectiveness of processes and systems, improve and identify the causes of incidents. Data can also be made available to other parties such as auditors, data subjects and data providers as part of the assurance process. Implications

• Data generated should be classified appropriately and may be considered sensitive.
• There will be a capacity (compute and storage) overhead to automated logging and so retention and logging level should be carefully considered.
• Logs related to a single process spread across systems may be difficult to maintain and so a central logging solution or method of combing logs may be required.

[manics]

Potentially several things then- which do you think are in scope?

• Logging: system logs, event/audit logs, data access logs, etc
• Monitoring: system performance, system failure, resource usage e.g. CPU/memory/storage
• Alerting: system failure, excessive unexpected resource usage
• Proactive alerting and remediation: e.g. running low on disk space
• API logs from external services

Would something like pending expiry of projects/users come into this section since it implies ongoing "monitoring" of user/project status, and you'd proactively alert them in case an extension is needed?

[machintim]

Yes, I think so. System/process observability is key to understanding whether your policies and controls are actually doing what is intended. You can write down "We remove access to data at the end of a contract" but unless you have data that proves you have actually done that, who is to say. That data could be a script and automated log or a calendar appointment and service desk ticket. The former obviously being preferable.

[harisood]

Sharing thoughts/updates from the Collab Cafe:

Statement

Human initiated and automated processes resulting in change within the TRE should be observable (in real time?)

Rationale

System/process observability is key to understanding whether your policies and controls are actually doing what is intended.

It also allows operators to continuously improve their systems and processes, measure their effectiveness, and identify the causes of incidents. Data can also be made available to other parties such as auditors, data subjects and data providers as part of the assurance process.

This applies to both technical systems and policies/processes.

Implications

• In order to understand what is happening within the TRE, both automated and human initiated processes should generate sufficient data. These data should follow standards for provenance and transparency for audit trails

Additional thoughts

• Observing needs to be transparent
• Is this real time or is it also about recording and defending? How does this relate to trust?
• Would you need a dashboard for surveillance and monitoring for TRE operators?
• What is a key action? What is being proactively helpful and what is being nosey? What granularity of logging do you go to?
• How do you monitor without intrusion on the confidentiality of a researcher’s requests or are at least be transparent about it? What things are useful to expose and what is worth keeping private?
• How does this question change for different personas, for instance the researcher, TRE operator, national auditor - what do they need to see and for what reason?