Secure Logging: logging of all operations/transactions is a critical requirement for secure data stores [Business Requirement]

[mwherman2000]

After reading several information security classification documents, it turns out that logging of all operations/transactions is a critical requirement for storing classified information.

Can it be done at a higher layer in the Secure Content Storage Stack? ...yes, but it wouldn't be as trustworthy as if logging was performed in the EDV Kernel.

[agropper]

+1 @mwherman2000 This observation is critical and part of the reason I keep trying to frame our SSI work in terms of Zero-Trust Architecture. Encryption, in the EDV sense, is not a panacea. It does provide plausible deniability to the EDV operator and protect the subject from some forms of censorship, but it also leaves open issues like forward secrecy, traffic analysis, and unintended consequences when platform operators run multiple seemingly separate services alongside EDVs.

[gobengo]

I wonder if EDV implementations could optionally return back metadata of an ‘audit log event’ from common vocabulary, including hash of event signed with same key as EDV. Then maybe ‘higher layer’ auditing systems could have the ‘trustworthiness’ of the EDV Kernel, but with EDV not having to do any configurable logging/shipping, just opting-in to higher layers via an extra metadata property semantically like ‘the activity that requested this EDV response’ (or something like that).

{ / ... other EDV ‘response’(?) message properties / // this is optional, but outer auditing layers may trust its signature auditLogActivity: { signature: 0xyz, content: { actor: ‘bengo’, @type: ‘edv:ReadKey’ key: ‘/foo/bar/bar’ } }, }

On Feb 20, 2021, at 08:00, mwherman2000 notifications@github.com wrote:

Can it be done at a higher layer in the Secure Content Storage Stack? ...yes, but it wouldn't be as trustworthy as if logging was performed in the EDV Kernel.

[mwherman2000]

For an CS version 1 implementation, simply logging into another encrypted container in the same data vault might be sufficient ...or something like that. No one can access the log entries without the appropriate authz (and presumably, this is at a level that is "higher" than what is needed to access access the base data itself).

[mwherman2000]

This includes all CRUD accesses including every read or attempted read. ...all successful as well as unsuccessful operation attempts.

[agropper]

I think the EDV default needs to be third-party audit. The keys are not an issue. The important thing is contemporaneous logs outside the EDV's control. Once the logs exist, the various participants can deal with who logs, who has access, with or without a court order, in real time, etc... as part of a service agreement.

Adrian

On Sat, Feb 20, 2021 at 3:33 PM mwherman2000 notifications@github.com wrote:

This includes all CRUD accesses including every read or attempted read. ...all successful as well as unsuccessful operation attempts.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/confidential-storage/issues/186#issuecomment-782745309, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YIG3H7VADHTJ4NUP63TAAMA5ANCNFSM4X575MMQ .

[mwherman2000]

I think the EDV default needs to be third-party audit.

Then an EDV data vault is no longer a confidential, secure content store. If a business application (i.e. client level) requires it, then that's a different issue at a different layer in the architecture.

[mwherman2000]

I'm realizing that almost everything I think about these days (e.g. this logging requirement) assumes there is an RDV Microkernel (or something equivalent)...

Content Change Detection is implemented in the EDV Microkernel in Layer A. Responsibility for Content Change Tracking and Notification is relegated to Layer B.

[neiljthomson]

From recent experience with an IoT project (CN - Canadian based North American Railway) complying with US legislation on Train Train safety (Positive Train Control/PTC which is now an international standard) and earlier experience with German Bank requirements for Analytic Query tools, which was also required by legislation, I would suggest there are requirements for logging at (minimum) 2 levels:

• API request/result logging (required) - this must be common across all EDVs and likely across all Digital Identity/Economy components (e.g., Issuer, Holder, Verifier):

  Log each API access capturing the requester and whether the access was accepted or rejected Log the API request parameters and whether the request succeeded or failed (and internal capture of the reason for rejection) In the case of a successful request, log some level of the returned response, up to and including full details (configurable) Logging capture can be to a (trusted) 3rd party logging service (via secure connection) or internal to the service Logging internally will require a secure API for log retrieval.

• Debug/internal failure trace/log (optional, but recommended - common API to access and adopting (an existing) logging format would be desirable (see reference to "I Heart Logs" book, below):

  When there is an internal error (or optionally for all operations when remote testing/debugging) a complete trace of the internal actions of the storage system, with configurable levels of capture (e.g., all transactions - during testing/acceptance or on a given level of error - e.g., Log4j levels). This is optional, but I don't know of too many systems that don't include something like this for "in the wild" problem resolution.

PS: I don't see these logging requirements for Digital identity based transactions NOT having these requirements introduced in legislation at some point if not already in place.

PPS: logging is just an assumption in the IoT (distributed system) space - see The Role of Logging in the Internet of Things, and I Heart Logs, written by the co-creator of Apache Kafka