Request for clarification on Object Storage control tests for CCC.ObjStor.C03

[sarahecraddock]

Support Question

I am working on the Azure Raid for Azure Blob Storage and I have a couple of questions around what was intended for specific control tests...

CCC.ObjStor.C03.TR01: Object storage buckets cannot be deleted after creation.
^ Is the above referring to soft delete, i.e. if containers are deleted they can be recovered?

CCC.ObjStor.C03.TR01: Retention policy for object storage buckets cannot be unset.
^ Is this referring to making the retention policy shorter or longer and what is an acceptable level of protection against retention policies being removed. For example Azure has immutability policies, which are intended for write once, read many data which can be time based or soft delete with a long lifetime and without the possibility of purging deleted data?

[mlysaght2017]

@sarahecraddock @eddie-knight:

CCC.ObjStor.C03.TR01
The control as currently defined is actually aiming to prevent deletion altogether rather than supporting a soft delete (which would allow deletion with the option to recover). I’s meant to enforce an irrevocable policy that blocks deletion attempts outright to avoid even temporary data loss.

If the intention were to enable a soft delete (i.e., allowing deletion with recovery options), the control and testing requirements would need some adjustments to reflect that and we would also need to align with relevant TLPs. So roughly something like:

text: Buckets are either irreversibly protected from deletion or, if allowed, soft deleted according to TLP.
tlp_levels:
- green: Soft delete allowed, with retention period enforced, allowing recovery of deleted buckets.
- red: Irrevocable delete prevention only—buckets cannot be deleted or soft deleted.

It's either that, a separate control entirely, or we just stick with the existing control and make clear it does not consider soft deletion.

[mlysaght2017]

CCC.ObjStor.C03.TR01
Is concerned with ensuring that retention policies are fixed once they are set, meaning they cannot be shortened, removed, or otherwise weakened after initial configuration.

Again, we may need to think more about acceptable levels of protection for different TLP levels. If we consider RED first, this might read something like:

Immutable retention policy cannot be modified or removed; allows extensions to retention period only.

[sarahecraddock]

Notes from working session call:

• Agreed current tests to refer to full immutability
• @mlysaght2017 to add additional tests for lower TLP levels which will look at soft delete rather than full immutability, for scenarios where full immutability isn't required.

[vrabotka]

Notes from the working group call for 469CCC.ObjStor.C03.TR01:

• The retention period will vary based on internal policy
• The control requirement is that the retention period is set to > 0
• The actual retention value is an input when running the test

[mlysaght2017]

@sarahecraddock - see #528 for attempt to separate out hard and soft delete controls based on TLPs