Auditing cloud apps
How should DICOM Audit logs reflect use of cloud apps and services
Cloud technology changes one of the simplifications used in the DICOM Security Audit Log. There was an underlying assumption that a data transfer was either internal to the security domain or across security domains. It’s either a “Data Transfer” (inside), “Export” (inside->outside), or “Import” (outside->inside).
Cloud implementations often have a shared security responsibility resulting in shared security domains. That means that the simple inside or outside distinction breaks down.
The choice between “Data Transfer” and “Export/Import” becomes a judgement call. The security organizations can make an administrative choice of which one to use to describe an event. Administrative roles can change, contracts can change, and cloud deployments can change. As a result, the security system will need to accept a degree of ambiguity in the choice of event. The degree of shared responsibility is dynamic. When analyzing logs the distinction between inside and outside becomes ambiguous and variable.
Fortunately, the three audit reports are very similar. They are all of the form:
This event took place (transfer/import/export)
The active participants were: A, B, C, …
The data transferred was: <list>
When we accept that the choice of transfer/import/export is partly a local administrative choice, the steps needed to reflect cloud deployments are:
Add cloud types to the active participant descriptions. This is probably just adding codes and definitions. With cloud deployments the identification of the participant can be different from the current network address information. Dynamic addition and removal of virtual machines and containers makes the IP address much less useful. But, the concept of a “name or ID” for the participant remains.
Modify the definitions of transfer/import/export to ensure that the new active participant types can be used to describe cloud interactions. Some of the requirements for the current events are based on clear division between inside and outside. These need to be revised to accommodate the shared responsibility of security in cloud deployments.
Accept that the three event types are no longer easily distinguished, and document this. Also document that changes to contracts, services, deployment, etc. can change security responsibilities and that the audit labels may lag and not match the details at the time of logging.
The description of the data transferred does not appear to be affected, although some of the DICOMWeb abilities to retrieve portions of images may be hard to describe. It’s probably not necessary to capture and distinguish between transfer of part of an image vs transfer of the entire image. (If this does need to be captured, the description of data transferred will need to be updated.)
Some follow-on questions are:
The current audit log captures application start and stop. How well does this capture dynamic configuration changes driven by load balancing, etc.? Is this something for DICOM Audit log to capture, or is this an example of the kind of information best captured by some other log in the cloud service provider?
Operational workflow optimization and tracking becomes much more significant when using fee for service and usage related billing. These are much more associated with cloud services than with internal services. Again, how much of this should be captured by the DICOM Audit log, some other audit log, or the cloud service providers log?